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\  Abstract  (unclassified) 


This  report  contains  a  survey  of  two  techniques  that  can  be  used  in  the  held  of  data  fusion;  temporal 
reasoning  and  tmth  maintenance.  The  automatic  hision  of  intelligence  repons  necessitates  talcing  into 
account  the  factor  time.  Incoming  messages  can  lead  to  new  interpretations  of  the  current  battlefield 
situation,  changing  previously  made  hypotheses.  A  dau  fusion  system  must  also  be  able  to  make  a  prediction 
of  what  sightings  are  to  be  expected,  e.g.  in  the  case  of  columns  of  vehicles  moving  pa-t  different  sensors. 
This  report  describes  a  temporal  database  system  that  can  capture  (some  pan)  of  the  volatility  of  the 
intelligence  pro^ssing  domain.  While  prtxxssing  intelligence  reports  there  is  always  an  amount  of 
uncertainty  and  incompleteness  that  has  to  be  dealt  with.  So  there  is  a  need  for  maintaining  different  lines  of 
reasoning  or  hypotheses  pertaining  to  the  battlefield  situation  concurrently,  and  incorporating  new 
information  as  it  becomes  available.  In  this  teixtrt  an  assumption-based  truth  maintenance  system  provides  a 
framework  in  which  this  proWem  can  be  solved.  A  prototype  has  been  developed  to  demonstrate  the 
applicability  of  the  aforementioned  techniques.  This  prototype,  called  Mefisto  (Modular  Environment  for 
Fusion  and  Interpretation  of  Sensor  data  in  Tracking  Opposing  forces),  is  a  simple  knowledge-ba^  system 
integrated  with  a  temporal  truth  maintenance  facility 
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Samenvjitting  (ongerubriceerd) 

Dit  rapport  bevat  een  overzicht  van  twee  techniekcn  die  kunnen  worden  gebniikt  op  bet  gebied  van 
datafiisie;  "temporal  reasoning"  en  "truth  maintenance".  De  automatische  fiisie  van  inlichtingenrapponen 
brengt  de  noodzaak  met  zich  mee  om  de  factor  tijd  in  de  beschouwing  te  betrekken.  Binnenkomende 
berichten  kunnen  leiden  tot  nieuwe  interpietaties  van  de  actuele  situaiie  op  bet  gevechtsveld,  waaibij  eerder 
opgesteldc  liypothesen  worden  aangepast.  Een  datafusie-systeem  ihoet  ook  in  staat  zijn  om  een  voorsnelling 
te  docn  over  te  verwachten  waamemingen  van  bijvooibeeld  kolonnes  voertuigen  die  zich  langs  veischiUende 
seasoren  voonbewegen.  In  dit  rapport  is  een  "temporal  database  system"  beschreven  dat  (een  deel  van)  de 
"vluchtigheid"  van  het  inlichtingenverwerkingsproces  kan  vangen.  Bij  het  verweiken  van  inlichtingen- 
rapporten  meet  altijd  rekening  gehouden  worden  met  een  bepaalde  mate  van  onzeketheid  en  onvoUedigheid. 
Hierdoor  ontstaat  de  noodzaak  om  tegelijkenijd  verschillende  iwJeneringen  of  hypothescr.  ten  aanzien  van  de 
situatie  op  het  gevechtsveld  te  onderhouden  en  deze,  zodra  nieuwe  infotmatie  beschikbaar  komt, 
overeenkomstig  te  wijzigen.  In  dit  rapport  is  een  "assumption-based  truth  maintenance  system"  beschreven, 
dat  een  opiossing  biedt  voor  deze  problemen.  Er  is  een  prototype  ontwikkeid  om  de  bruikbaaiheid  van  de 
eerder  genoemde  technieken  te  demonstreren.  Dit  prototype,  genaamd  Mefisto  (Modular  Environment  for 
Fusion  and  Interpretation  of  Sensor  data  in  tracking  Opposing  forces),  is  een  eenvoudig  kennissysteem 
gefntegreerd  me»  faciliteiten  voor  "temporal  truth  maintenance". 
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1  Introduction 

This  report  is  a  sequel  to  (Keene  Sl  Perre,  1990],  which  gave  a  general  overview  of  various 
approaches  to  data  fusion  in  the  military  intelligence  processing  domain.  In  the  following  chapters 
we  will  focus  on  two  techniques  which  are  of  importance  to  an  automatic  data  fusion  system: 
temporal  reasoning  and  truth,  maintenance. 

Terhporal  reasoning  is  "reasoning  about  time".  In  itself  this  statement  may  not  seem  that 
surprising.  Of  course  automated  real-time  systems  exia  that  interact  with  physical  processes  in 
the  real  world:  these  syaems  have  to  keep  track  of  time,  in  one  way  or  another.  However,  an 
important  observation  can  be  made  in  the  command  and  control  domain:  not  many  systems  are  in 
use  that  can  reason  about  time.  Especially  the  process  of  data  fusion  is  tightly  connected  with 
time.  Sensor  data  arrrives  at  different  points  in  lime,  without  the  assurance  that  it  can  be 
interpreted  and  processed  sequentially.  It  can  be  stated  that  in  data  fusion  applications  the  non¬ 
monotonic  charaaeristics  prevail. 

Truth  maintenance  is  a  method  to  monitor  the  truth  status  of  elements  in  a  data  base  system.  This 
status  may  depend  on  assumptions  which'  lay  at  the  toots  of  these  data  elements.  Should  these 
assumptions  become  invalid,  then  the  truth  stanis  of  conclusions  which  they  support  (i.e.  other 
data  elements)  also  changes.  A  truth  maintenance  system  provides  a  framework  in  which 
dependencies  between  data  elements  can  be  represented  explicitly.  If  there  is  some  change  in  one 
element,  then  the  consequences  for  other  elonents  which  are  dependent  on  it,  will  be  deduced. 

While  processing  intelligence  reports  temporal  reasoning  and  truth  maintenance  are  to  an  extent 
complementary.  Suppose  that  at  one  point  in  time  there  is  a  teitain  amount  of  information 
available  from  which  conclusions  about  the  battlefield  situation  can  be  drawn.  This  information 
and  the  ensuing  conclusions  could  be  called  "time-stamped".  If  at  some  later  point  in  time 
additional  information  becomes  available,  contradicting  or  augmenting  infbimation  already 
received,  it  could  be  necessary  to  adapt  earlier  made  conclusions  concerning  the  battlefield. 

The  following  topics  are  presented  in  the  remainder  of  this  report.  Chapter  2  gives  a  mote  general 
description  of  temporal  reasoning  and  truth  maintenance.  The  interest  is  focused  on  different 
approaches  to  temporal  reasoning  and  the  relation  between  this  technique  and  data  fosiorL  A 
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concise  treatment  of  non-monotonic  reasoning'  forms  the  starting  point  of  the  discussion  on  truth 
maintenance  systems,  culminating  in  a  presentation  of  the  assumption-based  variety.  These 
theoretical  notions  ure  operaticmaiizul  in  chapter  3,  which  contains  a  description  of  the  analysis 
and  design  process  of  the  Mefisto  prototype  (Modular  Envirr  oment  for  Fusion  and  Interpretation 
of  Sensor  data  in  T.ncking  Opposing  forces).  After  defining  the  battlefield  environment,  two  main 
points  are  addressed.'  Firstly,  the  structure  and  functionality  of  MeHsto.  Secondly,  the  extent  to 
which  the  theoretical  notions  of  the  previous  chapter  have  been  incorporated  into  this  prototype 
system.  Chaptef  4  contains  the  conclusions  and  recommendations  based  on  our  experiences  while 
building  Mefisto.  After  summing  up  the  acronyms,  abbreviations  and  references,  this  report 
concludes  with  appendices  containing  excerpts  from  the  Mefisto  code  for  the  temporal  query 
laitguage,  the  assumption-based  truth  maintenance  system  and  the  interaction  between  these  two. 
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2  Temporal  reasoning  and  truth  maintenance 

2.1  Introduction 

The  main  goal  of  data  fusion  is  to  combine  the  available  data  on  a  certain  area  of  interest  to 
achieve  as  best  an  estimate  as  possible  of  the  objects  in  the  area,  their  groupings,  movements  and 
combat  activities.  The  data  may  come  from  different  sensors,  is  governed  by  uncertainty  and 
incompleteness,  and  are  "snapshots”  of.a  continuously  changing  domain.  We  note  the  distinction 
between  sensor  fusion,  which  refers  to  the  correlation  of  low-level  sensor  data  (e.g.  radar,  infra¬ 
red),  and  data  fusion,  which  is  mainly  concerned  with  combining  data  from  the  vehicle  level  up  to 
complex  unit  aggregations. 

Generally,  information  in  the  form  of  incoming  reports  will  define  some  activity  associated  with  a 
unit  of  an  opposing  force,  describing  vehicle  types,  equipment  and  personnel  sighted,  movements 
with  an  associated  direction  and  speed,  location  and  time  of  the  sighting.  It  must  be  decided  what 
type  of  unit  the  report  describes  and  possibly  the  identity  of  the  unit.  This  classification  associates 
the  report  with  a  specific  unit  typi’i.  An  attempt  is  made  to  confirm  the  sighting  by  checking  units 
established  from  earlier  teports,  to  .tee  if  and  how  the  information  matches  the  current  krrown 
situation.  It  will  often  be  the  case  that  there  is  no  unique  solution  for  the  correlation  of  the 
reported  information,  a  report  may  refer  to  a  unit  associated  with  an  earlier  report,  but  it  may  be 
another  unit,  not  currently  kmwn  to  exist  on  flic  battlefield.  Thus,  it  will  be  necessary  to  keep 
track  of  units  in  both  space  and  time.  When  separate  units  have  been  distinguished,  the  next  step 
will  be  the  aggregation  of  units  into  larger  unit  formations.  The  propagation  of  assumptions  when 
e.g  a  unit  i'-  aken  to  be  such  and  such  or  assumed  to  be  part  of  a  certain  encompassing  unit  has  to 
be  tracked  as  well.  Consequently,  it  wilj  be  necessary  to  maintain  multiple  lines  of  reasoning 
about  the  area  of  interest. 

Temporal  aspects  predominate  in  d.ita  fusion.  In  tlie  first  place,  the  situation  at  time  now  based  on 
the  current  information  is  important.  Typically,  the  currently  available  information  taken  at  face 
value  will  not  be  sufficient  for  determining  a  coherent  picture  of  the  actual  situadoa  It  is 
necessary  to  be  able  to  engage  in  some  form  of  predictioa  An  example  is  the  tracking  of  units  in 
the  system  to  answer  queries  such  as  "Which  units  could  be  in  the  vicinity  of  location  X  within 
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one  hour  from  now?"  An  answer  involves  estimating  the  zone  that  is  relevant,  establishing  the 
units  that  are  in  that  zone  at  time  now,  associating  infonnation  as  to  velocities  and  movement 
capabilities,  direction  of  movement,  etc.  This  also  serves  to  indicate  that  temporal  reasoning  is 
very  closely  related  to  spatial  reasoning. 

Apart  from  prediction,  a  retroactive  adaptation  of  the  current  situation  will  often  be  necessary. 
This  is  the  case  when  for  instance  an  incoming  report  provides  information  contradicting  a 
previous  report,  but  also  applies  to  sensors  such  as  a  drone,  an  unmaitned  airborne  sensor  that  may 
provide  information  only  after  its  flight.  Both  predictive  and  retroactive  adaptations  therefore 
require  a  mechanism  for  recording  assumptions  that  may  at  a  later  stage  become  invalid. 
Temporal  reasoning  thus  requires  a  form  of  truth  maintenance,  and  as  outlined  above  so  does  the 
very  nature  of  data  fusion.  The  assumption-based  truth  maintenance  system  (ATMS)  is 
recognized  as  the  most  jHomising  means  for  this  purpose.  This  chapter  addresses  techniques  for 
both  temporal  reasoning  and  truth  maintenance. 

2.2  Temporal  reasoning 

2.2. 1  Approaches  to  temporal  reasoning 

Time  is  3  significant  factor  in  common-sense  reasoning,  yet  it  is  not  actually  dealt  with  in 
conventional  database  systems.  The  contents  of  the  database  are  considered  to  be  tinielessly  tme, 
defied  only  by  the  explicit  deletion  from  the  database.  The  idea  behind  a  temporal  database  is  to 
represent  the  notion  that  information  about  the  world  is  generally  incomplete  and  continuously 
changing.  An  important  aim  is  to  take  into  account  that  there  are  many  possible  states  of  affairs 
(worlds,  contexts,  situations),  based  on  conditional  predictions  to  fill  gaps  resulting  from  the 
incompleteness  of  information.  The  known  information  is  stored  in  a  temporal  database,  and  a 
problem  solver  constructs  a  number  of  possible  completions  of  the  knowledge,  choosing  the  most 
likely  solution.  This  can  not  be  represented  by  the  "timelessly  true"  facts  in  e.g.  a  relational 
database,  and  without  some  method  of  completing  this  knowledge,  because  this  would  add  up  to 
exactly  one  state  of  affairs. 

Taking  the  relational  database  model  as  the  current  convention,  we  have  a  collection  of  relations, 
each  relation  consisting  of  a  set  of  tuples  with  an  equivalent  set  of  attributes,  represented  as  tables.  , 
The  current  contents  of  the  tables  form  the  state  of  the  database,  adapted  by  the  operations  insert. 
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delete  and  update.  Only  the  current  State  nf  the  database  is  retained,  past  states  are  discarded.  An 
extension  of  this  is  the  representation  of  the  historical  state  per  lelation  in  a  historical  database. 
Previous  sutes  of  the  database  ate  not  reuined  as  such,  but  are  represented  in  the  history  ot  each 
relation  in  the  database.  Modincations  can  be  made  to  the  relations  when  etrots  are  detected  or  in 
answer  to  update  requests.  This  is  accompli^ed  by  adding  historical  records  each  time  an  entry  is 
updated.  Thus,  historical  databases  suppon  arbitrary  modification  and  represent  current 
knowledge  about  the  present,  as  do  conventional  databases,  but  they  also  represent  current 
knowledge  about  the  past.  An  example  of  a  (laboratory)  database  management  system  (DBMS) 
that  offers  facilities  for  the  implementation  of  a  historical  database  is  POSTGRES  ([Sionebraker 
et  al.,  1986:  itonebrakcr  et  al.,  1990)).  A  further  extension  is  outlined  in  [Snodgrass  &  Ahn, 
1986).  for  a  bibliography  on  temporal  databases  we  refer  to  [Stam  &  Snodgrass,  1989). 

A  more  formal  view  is  the  approach  taken  when  applying  temporal  logics  (modal  logics)  by 
extending  the  predicate  calculus  with  temporal  operators,  describing  notions  such  as  "always  from 
now  on",  "some  time  in  the  past",  etc.,  formulated  in  the  context  of  a  possible  worlds  semantics. 
For  instance,  the  notion  “P  was  valid  at  some  time  T"  would  be  true  if  P  is  true  in  all  possii,:e 
worlds  "covering"  T.  The  strict  formalism  ensures  that  logic  programs  governed  by  temporal  logic 
are  consistent  and  complete,  however  this  formalism  is  a  major  drawback  as  well,  due  to  the 
unnatural  representation.  There  is  a  large  number  of  theories  on  remporal  logic,  we  refer  to 
[Galton,  1987). 

Taking  in  mind  our  domain,  we  are  interested  foremost  in  the  following  sequence  of  activities:  the 
recording  of  incoiiiing  messages,  which  are  transferred  into  battlefield  entities,  which  in  turn  are 
grouped  into  formations  corresponding  to  known  data  on  order  of  battle.  A  data  fusion  system 
needs  the  functionality  of  retroactive  adaptation  of  database  records.  The  history  of  the  actual 
situation  at  some  time  is  extremely  imponant.  When  new  information  points  out  that  wnat  was 
thought  to  be  a  tank  battalion  was  in  fact  a  complete  regiment  it  must  be  possible  to  update  this  in 
the  corresponding  (historical)  tuple  in  the  database.  This  is  further  clarified  by  taking  in  mind 
situation  assessment  and  anticipation  of  fiiture  enemy  movements. 

It  is  our  view  that  temporal  information  in  the  context  of  data  fusion  can  be  sufficiently 
represented  by  facilities  supponing  historical  queries.  We  advocate  an  approach  that  lies 
somewhere  in  between  the  above,  such  as  used  in  the  planning  system  Time  Map  Manager 
(TMM)  of  Dean  [Dean,  1985;  Dean.  1986;  Dean  &  McDermott,  1987;  Firby  &  McDermott, 


1987],  It  is  a  computational  approach,  centering  around  techniques  for  managing  a  database  of 
assertions  corresponding  to  the  occurrence  of  everts  and  the  persistence  of  their  effects  over  time. 
The  approach  takes  into  accouitt  that  temporal  information  is  incomplete  and  defeasible. 
Therefore,  the  approach  stresses  the  necessity  that  a  problem  solver  has  to  be  able  to  make 
predictions  on  the  basis  of  certain  ass’imptibns,  that  these  assumptions  may  at  some  later  time 
become  invalid  and  hence  the  predictions  based  on  these  assumptions  as  well.  Moreover,  it  is 
recognized  that  most  common-knse  reasoning  involves  reasoning  about  temporal  events  and  that 
durations  of  events  ate  often  knotvn  within  metric  bounds.  This  is  reflected  in  the  choice  of 
''bringing  time  into  the  relations",  replacing  classic  assertions  by  data  suvetures  incoiporating 
interval  repre.sentations  of  temporal  validity.  We  will  take  this  approach  as  a  staning  point,  with 
the  main  objective  of  determining  if  and  how  it  can  be  utilized  for  the  repre^ntation  of  temporal 
dependencies  in  the  domain  of  data  fusion.  .  , 

2.2.2  Temporal  reasoring  and  data  fusion 

The  strategy  behind  temporal  reasoning  is  what  [Dean  &  McDermott,  1987]  refer  to  as  shallow 
temporal  reasoning.  Shallow  temporal  reasoning  is  characterized  by  breaking  down  the  reasoning 
process  into  the  following  steps; 

1 .  Generate  a  set  of  candidate  hypotheses; 

2.  Seiect  one  hypothesis  from  among  the  candidates; 

3.  Use  the  selected  hypothesis  as  a  basis  for  prediction; 

4.  Respond  to  unforeseen  consequences  noticed  in  the  course  of  prediction. 

The  hypotheses  correspond  to  the  possible  states  of  affairs,  which  are  the  result  of  the  known 
information  on  events,  their  effeas,  their  time  of  occurrence  and  duration.  For  instance,  a 
hypothesis  based  on  the  sightings  of  cenain  units  in  each  other's  vicinity  could  be  the  indication  of 
the  p  esence  of  a  larger  encompassing  unit. 

TIk:  selected  hypothesis  is  then  the  basis  for  making  predictions  depending  upon  the  hypothesis. 
Predictive  inferences  can  take  the  form  of  what  Dean  calls  controlled  forward  irtferences  or 
automatic  projections  [Dean,  1986].  Controlled  forward  inferences  are  achieved  by  the 
application  of  forv/ard  chaining  rules,  directly  adding  deductions  to  the  database  (for  example,  the 
deduction  that  a  new  report  refers  to  a  tank  company  because  the  conditions  as  to  vehicle  types 


TNOrapoct 


Page 

12 


and  quantities  are  satisfied).  Automatic  projection  is  a  mechanism  that  responds  to  trigger-events. 
If  antecedent  conditions  are  satisfied  and  a  trigger  event  occur;  then  after  some  delay  a 
consequent  effect  is  added  to  the  database. 

Finally,  the  fourth  step  is  described  as  responding  to  unforeseen  consequences  noticed  in  the 
course  of  prediction.  It  entails  foremost  the  need  for  truth  maintenance,  for  keeping  track  of  the 
assumptions  underlying  a  certain  hypothesis,  and  when  assumptions  become  invalid,  invalidating 
the  hypothesis  and  replacing  it  by  another. 

The  above  cyclic  description  of  shallow  temper?!  reasoning  is  in  effect  a  concise  formulation  of 
the  essential  process  underlying  data  fusion.  As  reports  containing  sensor  data  are  transferred  into 
associated  units  by  a  classification  process,  hypotheses  are  generated  concerning  the  type  of  unit 
invol'.ed.  A  unit  is  assumed  to  have  some  unit  type  at  say  time  Tg,  at  a  later  time  Tj  the  unit  is 
aggregated  into  a  larger  unit,  which  will  be  further  used  for  concluding  aspects  about  the 
battlefield  situation  at  time  T2.  When  information  at  time  T3  allows  the  conclusion  that  the 
classificatior  of  the  unit  was  incorrect  after  all.  all  inferences  made  since  then  using  the  unit 
classification  as  a  condition  must  be  defied.  This  work  is  done  by  a  truth  maintenance  system, 
which  must  reply  with  a  list  of  the  conclusions  added  to  the  database  that  are  thus  defied. 
Effectively,  the  database  situation  must  then  be  fumed  back  to  tirne  Tg  in  the  sense  that  the 
conclusions  are  removed  from  the  database  (in  fact,  they  will  not  be  deleted  but  "clipped"  with  Tj 
as  endtime,  we  refer  to  the  next  paragraph)  and  an  optional  re-run  of  the  inference  mechanism 
with  the  new  unit  type  at  Tg  will  then  re.sult  in  new  conclusions,  effective  fiom  some  time  T4. 

A  temporal  reasoning  application  will  typically  require  a  temporal  database,  a  (temporal)  query 
language,  an  inference  mechanism  and  some  form  of  truth  maintenance  system  [Dean  & 
McDermott,  19871.  A  problem  solver  will  incorporate  a  temporal  query  language  and  an  inference 
mechanism.  Temporal  as.sertions  are  stored  in  a  database,  which  can  be  queried  by  the  problem 
solver.  The  temporal  assertions  and  derivations  based  on  these  assertions  are  passed  to  a  truth 
maintenance  system  (FMS),  which  performs  the  bookkeeping  of  assumptions  and  justifications, 
and  has  access  to  the  database  as  well.  The  TMS  notifies  the  problem  solver  of  changes  in  the 
validity  of  nodes.  The  main  notions  concerning  the  temporal  database,  a  temporal  query  language 
and  inference  will  be  addressed  in  the  next  paragraph.  Truth  maintenance  is  addressed  in  section 
2.3. 
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2,2.3  A  '.emporal  taxonomy 

The  ba.sic  temporal  notion  is  the  interval.  An  interval  is  a  pair  of  points,  consisting  of  a  begin-  and 
an  endpoint,  such  that  Cie  beginpoint  pt -cedes  or  coincides  with  the  endpoint.  In  the  latter  case  it 
is  a  single  timepoint.  which  is  thus  represented  in  two  dimensions  as  an  interval  (poinUpoint). 

An  occation  (Dean  also  refers  to  "time  token")  ;s  a  fact  or  instantiated  proposition.  It  has 
associated  with  it  a  temporal  distance  statement  that  we  will  call  timedist,  which  i.s  the  central  data 
structure  contained  in  the  temporal  database.  The  timedist  stmeture  represents  the  duration  of  an 
occasion,  stating  the  begin-  and  endpoints,  constrained  within  a  lower  bound  and  an  upper  bound. 
The  following  representation  of  the  timedist  structure  is  the  notation  in  Prolog: 

timedist (begin (Occasion) ,end(C:casion) ,Low^High) . 

The  timedist  structure  records  relative  time,  and  ab..iute  time  is  calculated  using  only  relative 
temporal  distances  (Dean  &  McDermott.  19871.  The  reason  is  that  Dean's  Time  Map  Manager 
concerns  the  domain  of  planning,  which  deals  mostly  with  relative  time.  e.g.  the  duration  of  taskl 
is  known  to  have  a  lower  bound  of  2Q  minutes,  and  an  upper  bound  of  35  minutes,  whereas  the 
precise  begin-  and  endtimes  of  taskl  arc  not  known  beforehand.  Njt  the  end  of  taskl  must  precede 
the  beginning  of  task2.  etc.  Thus  the  minimum  and  maximum  durations  of  an  occasion  are 
recorded,  related  to  the  begin-  and  endpoints,  which  arp  expressed  as  ”begin(Occasion)"  and 
"end(Occasion)".  The  domain  of  data  fusion  also  incorporates  relative  temporal  irtformabon.  e.g. 
it  may  be  known  that  the  displacement  of  a  unit  from  location  A  to  location  B  has  a  cenain 
duration,  or  that  given  the  sighting  of  some  unit  this  implies  that  a  certain  other  unit  is  expected  to 
pass  within  an  hour. 

The  timedist  structure  explicitly  contains  relative  temporal  information.  However,  it  implicitly 
,  represents  absolute  temporal  information,  which  will  be  explained  further  on.  This  allows  the 
representation  of  default  information,  because  given  a  timepoint  and  an  occasion  such  that  its 
begin-to-end  interval  does  not  contain  that  timepoint,  this  implies  that  the  occasion  was  not  valid 
at  that  time.  This  is  a  powerful  way  of  recording  historical  information.  It  is  comparable  in  its 
intention  to  a  two-dimensional  indexing  method  for  geographic  database  applications  using 
"minimal  bounding  rectangles"  for  the  storage  of  geographic  information,  as  opposed  to  the 
conventional  one-dimensional  indexing  methods. 
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To  calculate  absolute  dine  from  relative  dme  it  is  necessary  to  adopt  some  referrnce  point  The 
registradon  of  temporal  information  for  an  occasion  of  which  the  begintime  is  known  is  then 
accomplished  by  assening  two  dmedist  entries  in  the  temporal  database,  the  fiist  containing  the 
entries  corresponding  to  the  reference  point  and  the  beginpoint  of  >he  occasion,  the  second 
containing  the  entries  for  the  begin-  and  endpoint  of  the  occasion.  For  example,  an  occasion  valid 
from  timepoint  until  timepoint  t2  is  entered  in  the  temporal  database  as  follows: 

timedist (ref (begin (Occasion) /tj, tj) . 

timedist  (begiri(Occasion)  ,end(;'cca3ion)  ,t2»t2)  . 

The  first  entry  has  tj  as  lower  and  upper  bound,  stating  that  the  occasion  is  known  to  exist  since 
timepoint  t].  The  second  timedist  entry  contains  the  information  related  to  the  endpoint  of  the 
occasion.  The  above  representation  suffices  for  the  calculation  of  all  temporal  distances,  acquiring 
a  powerful  mechanism  for  the  calculation  of  temporal  distances  between  occasions  with  relative 
timepoints,  while  obtaining  absolute  time  from  these  relative  temporal  dependencies  by  the 
calculation  of  the  shortest  possible  path  from  A  to  B. 

There  is  a  visual  representation  of  the  temporal  notions  {temporal  imagery),  the  construction  of 
time  maps.  In  figure  2.1  a  time  map  is  showa  A  time  map  is  a  graph  with  vertices  referring  to 
points  in  time,  and  disunce  constraints  between  the  points  of  the  graph  along  the  directed  edges. 
The  notation  (A,B)  in  fig.  2.1  corresponds  to  the  minimal  and  maximal  di.stance  between  two 
points.  These  may  be  negative  distances,  indicating  ''travelling"  in  the  past.  Thus,  we  can 
calculate  the  distance  bounds  in  going  from  say  pt]  to  pt2.  In  the  example  there  are  three  possible 
paths  leading  from  ptj  to  pt2,  two  of  which  traverse  pt3  on  route. 

There  is  an  important  distinction  between  three  types  of  (temporal)  distances;  a  simple  distance 
function  conneaing  two  separate  points  (as  captured  by  the  timedist  data  stmeture),  the  dis'.ance 
function  corresponding  to  the  distance  of  a  path,  and  the  distance  that  represents  the  greatest 
lower  bound  (GLB)  and  least  upper  bound  (LUB)  of  the  distances  of  these  paths,  thus  the  shortest 
path.  In  the  case  of  figure  2.1,  the  timedists  are  the  four  separate  distances.  The  three  available 
paths  from  ptj  to  pt2  have  respective  distances  [5.9].  [6.8]  and  [-1,111.  On  aggregation  of  the 
minimum  and  maximum  bounds  of  these  paths  the  distance  representing  the  GLB  and  LUB  is 
16,8). 


Figure  2.1:  Time  map  illustrating  distance  cortstiaints  St.  McDermott,  1987] 

We  will  hinher  illustrate  the  temporal  notions  with  an  example.  We  refer  to  Appendix  A  for  a 
listing  of  the  Prolog  source  code  of  the  predicates  used  below.  We  have  two  occasions,  occl  and 
occ2.  We  add  the  following  entries  to  the  temporal  database: 

timedist (ref .begin (occl) ,100,100). 
tittiedist  (begin  (occl)  ,end(occl) ,  0,  inf )  . 
timedist (ref .begin {occ2) ,150,150). 
timedist (begin (occ2) ,end(occ2) , 10, 30) . 

This  implies  that  occl  is  valid  from  timepoint  100  on,  and  occ2  is  valid  from  timepoint  iSO  with  a, 
duration  betwt"n  10  and  30  time  units.  We  have  implemented  a  temi.oral  distance  function  with  a 
shortest  path  calculation  as  explained  above.  When  we  query  the  distance  from  begin(occl)  to 
end(occ2)  the  result  is  the  following: 

I  ?-  temporal_distance{begin(occl) ,end(occ2) ,Min,Max) . 

Min  -  60, 

Max  -  80. 

This  illustrates  that  absolute  time  is  derived  from  relative  temporal  instances,  via  the  reference 
point  "rer.  The  temporal  dependency  between  occl  and  occ2  is  not  exjSicitly  entered  into  ttie 
temporal  database,  but  calculated  via  the  reference  point. 
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Querying  the  lower  and  upper  bounds  of  an  occasion  results  in  the  following,  stating  that  occ2 
starts  at  time  point  ISO,  and  ends  between  time  points  160  and  180. 

I  ?-  temporal_bound3 (occ2) . 

[ref (begin (occ2) , 150,150] 

'  [ref, end(occ2) ,160,180) 

A  temporal  query  language  is  necessary  to  further  use  the  temporal  database  for  determining  e.g. 
whether  a  certain  point  comes  before  another  point,  whether  an  occasion  is  true  throughout  a 
specific  interval,  whether  two  occasions  are  overlapping.  Effectively  these  requirements  above  arc 
met  by .  predicates  that  represent  notions  such  as  "timepoint  less  than"  and  "occasion  true 
throughout  an  interval"  that  can  be  used  in  temporal  queries.  These  predicates  concern  the 
temporal  relatioas  between  occasions  and  time  points,  among  occasions,  and  between  occasions 
and  intervals.  They  are  implemented  as  backward  chaining  rules.  In  this  way  a  powerful 
mechanism  is  developed  for  querying  the  implicit  temporal  dependencies  among  the  various 
occasions.  Beside  the  timedist  instances  entries  of  predicates  of  the  temporal  query  language  such 
as  "during"  and  "uue_throughout"  can  be  asserted  directly  to  the  temporal  database  as  well. 

The  following  is  an  example  of  a  predicate  of  the  temporal  query  language,  which  when  called 
upon  calculates  those  occasions  that  satisfy  the  coridition  that  the  period  in  which  Occl  is  valid 
lies  completely  inside  the  period  that  Occ2  is  valid.  We  refer  to  Appendix  A  for  a  complete  list 

during(6ccl,Occ2) 

tempera l_di3tance (begin (Occl) ,end(Occl) , Mini, Maxi) , 
temporal_di3tance (begin (Occ2) ,end(Occ2) ,Min2^Max2) , 
not (Occl  ”  Occ2), 
le33__equal(Min2,Minl) , 
le33_equal(Maxl,Max2) . 

For  the  example  above,  this  query  results  in  the  following  answer,  meaning  that  occ2  is  found  to 
occur  during  occl. 

I  ?-  during  (X,y)  . 

X  -  occ2,  Y  -  occl'. 
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There  is  a  distinction  between  two  types  of  occasions.  Firstly,  an  event  refers  to  an  occasion  with 
a  duration  that  can  be  reasonably  predicted,  such  as  the  take-off.  of  an  airplane,  or  the  movement 
of  a  tank  company  from  location  X  to  location  Y.  In  the  example  above,  occ2  is  an  event 
Secondly,  a  persistence  is  an  occasion  applicable  to  change  over  time.  Persistences  reflea  what  is 
believed  to  have  occurred,  and  by  default  the  upper  bound  of  a  persistence  is  set  to  infmite  (the 
occasion  is  assumed  to  be  persistent).  In  the  example  above  occl  is  a  persistence,  with  its  upper 
bound  set  to  infinite. 

A  mechanism  referred  to  as  clipping  chtmges  persistences  into  clipped  persistences  when  called 
for,  indicating  that  the  occasion  is  no  longer  valid  as  from  the  inserted  cliptime.  This  clipping  is 
essentially  the  replacement  of  an  endtime  (generally,  with  an  earlier '  endtime),  and  an' 
accompanying  replacement  of  the  upper  bound.  Often,  the  clipped  occasion  will  be  a  persistence 
with  an  upper  bound  "infinite”  between  begin-  and  endpoint.  The  upper  bound  is  replaced  by  the 
time  corresponding  to  the  beginpoint  of  some  later  occasion  replacing  it.  To  further  illustrate  the 
clipping,  we  list  the  temporal  bounds  of  occl  from  the  example  above  and  clip  the  occasion: 

I  ?-  temporal_bounds (occl) . 

[ref /begin (occl) , 100, 1001 
[ref, end (occl) , 100, inf ] 

I  ?-  clip_node (occl, 190) . 

Due  to  the  relative  notions  involved,  the  result  of  the  clipping  is  that  the  second  timedist  entry  is 
updated.  Initially,  the  lower  and  higher  bound  were  0  and  inf,  these  are  replaced  by  the  difference 
between  the  cliptime  and  the  begintime.  In  the  case  bf  occl,  the  timedist  entries  become  as 
follows: 

timedist (ref /begin (occl) ,  100, 100)  . 
timedist (begin (occl) ,end(occl) , 90, 90) . 

Figure  2.2  below  illustrates  the  clipping  mechanism  for  the  example  that  was  given  here. 


before 


after 


too  '190 
occi 


not(occl) 


Figure  2.2:  Time  map  illustrating  die  clipping  of  an  occasion 

Now,  when  the  temporal  bounds  are  calculated,  the  result  is  the  following; 

I  ?-  temporal_bounds  toed)  . 

(ref , begin (ocel) , 100, 100} 

[ref, end(occl) ,190,1901 

The  inference  mechanism  in  a  temporal  database  application  uses  three  types  of  rales:  backward 
chaining  n\cs,  forward  chaining  rules  and  clipping  rales.  The  backward  chaining  rales  are  used, 
as  stated  above,  for  the  implementation  of  the  temporal  queries.  The  forward  chaining  rales 
contain  the  domain  knowledge  and  will  be  used  to  perform  tasks  corresponding  to  Classification 
and  prediction.  Oipping  rales  respond  to  the  occurrence  of  apparently  contradictory  occasions  - 
for  instance,  "unit  X  non-active"  and  "unit  X  active"  -  by  clipping  the  earlier  occasion,  thus 
forcing  its  endtime  to  precede  the  beginning  of  the  later  occasion. 

The  basic  temporal  taxonomy  described  provides  a  quite  natural  common-sense  representation  of 
time.  The  history  of  database  entries  is  implicitly  contained  in  the  represemation  of  begin-  'and 
endpoints  in  an  accompanying  temporal  relation.  A  problem  is  posed  by  the  question  of  control: 
how  should  the  various  rales  be  applied.  The  application  of  temporal  reasoning  will  be  further 
addressed  in  the  next  chapter,  in  combination  with  the  application  of  truth  maintenance,  which  is 
the  subject  of  the  next  paragraph. 
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’  2.3  Truth  maintenance 

2.3.1  Non-monotonic  reasoning 

The  ability  to  reason  about  and  adapt  to  a  changing  environment  is  an  important  aspect  of 
intelligent  behaviour.  Given  a  system  that  performs  reasoning  (if  <condition>  then  <conclusion>), 
adaptation  requires  the  ability  to  alter  conclusions  when  conditions  are  contradicted  or  no  longer 
met.  This  implies  that  monotonic  behaviour,  i.e.  the  strict  growth  of  derived  facts  in  a  reasoning 
system,  is  not  satisfactory.  The  conclusions  in  a  context  of  incomplete  knowledge  are  tentative, 
meaning  that  they  can  be  withdrawn  when  new  information  makes  this  necessary.  The  reasoning 
system  has  to  keep  record  of  all  tentative  conclusions  reached  and  whether  they  are  believed  or 
disbelieved. 

There  are  quite  a  few  mechanisms  that  perform  non-monotonic  reasoning,  among  them  default 
logics  such  as  established  by  (Reiter,  1980),  non-monotonic  logics  of  e.g.  (McDermott  &  Doyle, 
1980],  methods  such  as  circumscription  (McCarthy,  1980],  and,  most  notably,  truth  maintenance 
:  systems.  Of  these,  the  original  TMS  (Doyle,  1979]  has  been  extended  with  assumptions  by 

(DeKleer,  1986a]  to  what  is  generally  known  as  the  ATMS,  the  assumption-based  truth 
maintenance  system.  The  latter  has  since  gained  a  widespread  recognition  and  is  in  our  view  the 
best  instrument  for  non-monotonic  reasoning,  due  to  the  appealing  representation  of  assumptions 
and  the  implicit  ability  of  representing  multiple  contexts,  entailing  the  representation  of  complex 
hypotjeses.  For  an  overview  cf  non-monotonic  reasoning  we  refer  to  (Ginsberg,  1987],  a  review 
of  the  literature  on  truth  maintenance  is  contained  in  (Stakenborg,  1989],  extensions  of  the  ATMS 
arc  given  by  DeKleer  in  (DeKleer,  1986b;  DeKleer,  1986c]. 

An  assumption-based  truth  maintenance  system  (ATMS)  is  meant  to  cooperate  with  a  problem 
solver.  The  problem  solver  gives  the  ATMS  "inferences”.  The  ATMS  in  turn  gives  the  problem 
■  solver  "beliefs".  The  ATMS  is  a  cache  for  all  the  inferences,  made  by  the  problem  solver.  It  also 
allows  for  non-monotonic  reasoning,  and  it  ensures  that  the  database  is  free  of  contradiaions. 
i  Figure  2.3  illustrates  the  basic  architecture.  We  note  that  the  terms  "reason  maintenance"  or 

‘  "belief  revision"  ate  also  used;  we  adhere  to  truth  maintenaiKe. 
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Figure  2.3;  Basic  problem-solving  architecture 

2.3.2  The  Assumption-based  Truth  Maintenance  System 

The  idea  behind  an  ATMS  is  the  maintenance  of  a  tree-structure  of  which  the  nodes  are  the 
statements  that  a  problem  solving  program  uses.  These  statements  may  be  premises,  assumptions, 
i.e.  statements  assumed  to  be  true  by  default  in  order  to  engage  in  predictive  reasoning,  or  derived 
nodes.  The  results  of  the  problem  solver  are  passed  as  "justifications"  to  the  ATMS,  which 
records  these  along  with  the  assumptions  they  rely  on.  When  new  information  points  out  that  an 
assumption  is  no  longer  valid,  this  is  pas.sed  to  the  ATMS  as  well,  which  then  proceeds  to  track  all 
justifications  that  used  the  assumption  as  an  antecedent,  and  records  these  as  being  no  longer 
valid.  Implicitly,  the  ATMS  contains  all  possible  hypotheses  derivable  from  combinations  of  all 
the  valid  assumptions. 

The  ATMS  constructs  a  dependency  network  consisting  of  nodes  and  justifications.  The  problem 
solver  as.sociates  a  datum  (a  fact,  complex  proposition,  etc.;  but  mote  importaritly  an  instantiation) 
with  the  node,  the  ATMS  maintains  the  belief  status  of  the  node.  An  assumption  results  in  an 
assumed  node,  a  special  type  of  node  that  normally  remains  unjustified  (justifies  itselO,  a  premise 
is  a  node  corre.sponding  to  a  basic  fact.  Other  node  types  are  based  oti  justifications  representing 
the  derivations  made  by  the  problem  solver,  describing  how  derived  nodes  depend  on  other  nodes. 
The  deperrdency  network  is  maintained  by  the  construction  of  environments,  beirig  sets  of 
assumptions.  Environments  ate  internal  representations  created  by  the  ATMS,  and  nodes  receive  a 
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label  as  a  pointer  to  the  environments  the.  node  is  valid  in,  i.e.  the  assumptions  the  node  is 
dependent  on. 

Justifications  are  expressed  in  the  fonn:  A, . A„->  C,  with  C  the  consequent  and  A  jto  A  ^ 

antecedents,  which  can  be  assumptions  or  non-assumption  nodes.  We  further  define  a  node  as 
valid  in  an  environment  E  if  and  only  if  it  can  be  derived  from  the  current  set  of  justifications 
using  only  the  assumptions  in  E.  An  environment  is  called  inconsistent  if  a  contradiction  is 
derivable  from  it.  In  the  ATMS  this  is  called  a  nogood  environment. 

We  will  illustrate  the  working  of  the  ATMS  with  an  example.  We  have  used  an  implementation  of 
the  ATMS  in  Prolog  listed  in  [Guoxing,  1989),  which  was  developed  at  the  University  of  Twente, 
the  Netherlands.  The  essential  source  code  penaining  to  the  ATMS  algorithm  is  listed  in 
Appendix  B,  as  well  as  adaptations  we  have  made  to  the  code  to  eliminate  errors  and  to  enable  the 
interaction  with  the  temporal  database.  The  example  below  does  not  incorporate  the  interaaion 
with  the  temporal  database,  this  will  be  addressed  in  the  next  chapter.  The  same  example  will  be 
used,  however,  therefore  the  treatment  here  is  kept  concise. 

We  have  several  (abstract)  nodes,  corresponding  with  the  four  occasions  occl  to  occ4.  We  add  the 
following  to  the  ATMS,  meaning  that  occl  is  a  premise,  occ2  an  assumption.  occ3  derived  from 
occ  1  and  occ2,  and  occ4  is  in  turn  derived  from  occ3; 

I  ?-  addi_premi3e  (occl) , 

add_assumption tocc2) , 

add_justif  ication  (occ3,  toed,  occ2) ) , 

add_justif ication(occ4, [occ31 ) . 

This  results  in  the  creation  of  the  premise,  assumption,  and  the  two  justifications  in  the  ATMS. 
The  ATMS  constructs  environments  as  weU,  and  attributes  labels  to  the  nodes.  The  nodes, 
justificctions  and  environments  can  be  listed.  We  will  illustrate  the  propagation  of  a  nogood 
assumption  through  the  ATMS  with  the  following  simple  example.  We  pass  the  node  occ2  as  a 
nogood  assumption  to  the  ATMS.  This  results  in  the  passing  back  of  a  list  of  the  nodes  set  to  our 
by  the  ATMS,  a  feature  which  we  have  added  to  the  implementation  of  [Guoxing,  1989]. 
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The  result  is  the  following: 

I  ?-  pass _nogood (occ2; List) . 

Setting  nogood;  occ2' 

Nodes  set  to  out  by  ATMS:  . 

List  ”  (occ2,occ3,occ4) . 

This  shows  that  the  nodes  occ3  and  occ4  are  set  to  out  as  well  as  a  result  of  passing  occ2  as  a 
nogood  assumption.  The  result  for  the  environment  consisting  of  the  assumption  occ2  is  that  the 
environment  is  set  to  be  contradictory  by  the  addition  of  the  node  "Contradiction”. 

Each  environment  induces  a  context,  being  sets  of  nodes  (assumptions  and  non-assumptions) 
valid  in  the  environment.  Thus  a  context  consists  of  the  assumptions  valid  in  a  consistent 
environment,  and  all  nodes  derivable  from  those  assumptions.  A  characterizing  environment  for  a 
context  is  the  set  of  assumptions  from  which  every  node  of  the  context  can  be  derived.  Now,  the 
main  task  of  the  ATMS  is  to  determine  whether  or  not  a  node  is  valid  in  a  given  context  This  is 
managed  by  the  maintenance  of  labels. 

Labelling  is  a  crucial  mechanism  in  an  ATMS.  A  label  is  a  set  of  environments  {Ei,...,E|() 
associated  with  each  node  N.  A  label  has  to  fulfil  four  requirements:  it  must  be  consistent,  sound, 
complete  and  minimal.  Consistency  means  that  no  Ej'  is  a  nogood  environment,  implying  that  all 
environments  containing  a  nogood  environment  as  a  subset  must  be  removed.  Soundness  means 
that  node  N  is  valid  in  each  Ej.  Completeness  implies  that  every  environment  E  in  which  N  is 
valid  is  a  superset  of  some  Ej.  Finally,  minimality  is  the  property  that  no  Ej  is  a  subset  of  any 
other,  which  implies  that  all  environments  that  are  subsumed  by  (are  superset^  of)  other 
environments  must  be  removed. 

Figure  2.4  is  an  example  of  an  environment  lattice,  the  result  of  only  five  assumptions.  An 
environment  lattice  contains  all  the  environments  in  the  ATMS,  with  the  empty  node  as  root  node, 
the  assumptions  in  the  ATMS  as  the  next  layer,  and  all  possible  combinations  of  these 
assumptions  in  the  intermediate  layers,  up  to  the  top  node  which  consists  of  all  assumptions. 
Given  n  assumptions,  there  are  2"  environments. 
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Figure  2.4:  Environment  lattice  [DeKleer,  1986a) 

However,  net  all  of  these  environments  will  be  used  for  derivations,  and  the  passing  of  nogood 
assumptions  causes  all  supersets  of  these  environments  to  be  removed  from  the  lattice.  This 
implies  a  lesser  complexity  when  using  an  ATMS  than  might  be  expected  when  amsidering  the 
complexity  of  the  environment  lattices. 

The  crossed  out  environments  in  the  lattice  of  figure  2.4  correspond  with  the  result  of  passing  the 
environment  |A,B,E)  as  a  nogood  environment  The  environments  that  have  been  crosised  out  are 
all  supersets  of  environment  (A,B£).  They  necessarily  become  nogood  as  well  because  they 
completely  subsume  the  latter  environment.  As  stated  above,  each  environment  induces  a  context, 
the  nodes  that  are  contained  in  or  can  be  derived  from  the  assumptions  contained  in  that 
environment.  The  oval  nodes  in  figure  2.4  represent  the  context  environments  of  an  ATMS  node 
with  label  {{A,B),(B.C,D}).  This  means  that  a  node  that  is  valid  in  the  environment  with  that 
label  will  also  be  valid  in  all  environments  that  are  supersets  of  the  two  environments  contained  in 
the  label.  In  the  same  way,  the  square  nodes  represent  the  context  environments  of  a  node  with 
{  (A,C),{DX)  )  as  label. 
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The  basic  ATMS-cycIe  is  the  creation  of  a  new  node  that  initially  gets  the  empty  label  {).  A 
problem  solver  damm  is  associated  with  the  node,  and  the  status  is  set  to  out.  The  next  step  is  to 
either  create  a  premise,  create  an  assumption,  or  to  add  a  justification.  A  premise  node  keeps  label 
I  ],  but  the  status  is  set  to  in.  An  assum|Xion  A  is  given  label  {[A]}  and  status  in,  and  is  in  faa  a 
justification  with  itself  as  antecedent  and  consequent.  As  stated  before,  the  antec^ents  of  a 
justification  must  be  either  premises,  assumptions,  or  other  previously  justified  nodes. 

Thus,  the  ATMS's  primary  objective  is  finding  a  consistent  and  well-founded' assignment  of  the 
states  (in  or  out)  of  the  nodes  which  are  neither  premises  nor  assumptions.  The  addition  or 
removal  of  a  justification  triggers  a  recomputation  of  the  environment  labels  of  some  subset  of  the 
set  of  nodes.'  It  is  not  our  intention  to  go  into  the  further  technicalities  of  the  reason  maintenance 
mechanism  here,  the  algorithm  is  described  in  (DcKleer,  1986a]. 


TNO  report 


Page 

25 


3  Prototyping  Mefisto 

3.t  Introduction 

This  chapter  deals  with  a  demonstration  program  we  have  developed  that  uses  a  combination  of 
assumption-based  truth  maintenance,  a  temporal  reasoning  mechanism  and  a  forward-chaining 
ruie-rir<iig  strategy  to  fuse  infomiation  contained  in  sample  reports  pertaining  to  a  battlefield 
situation.  T.ve  name  "Mefisto"  is  an  acronym  for  "Modular  Environment  for  Fusion  and 
Interpreta'ion  of  Sensor  data  in  Tracking  Opposing  forces".  The  con.oination  of  the  above 
techniques  is  demonstrated  to  be  a  powerful'  tool  in  addressing  some  major  problem^  in  data 
fusion;  the  incorporation  of  temporal  reasoning  facilities,  a  retroactive  adaptation  of  the 
(temporal)  database  and  the  maintenance  of  concurrent  hypotheses  concerning  the  current 
battlefield  situation. 

We  stress  that  the  intention  was  to  investigate  the  application  of  the  above  techniques  to.  the 
domain  of  data  fusion.  This  implies  that  assumptions  have  been  made  be  forehand  that  restrict  the 
notion  of  "data  fusion"  in  the  context  of  the  application  described  in  this  chapter.  The  domain  is 
hypothetical  in  the  sense  that  it  mtiy  not  be  compared  to  the  existing  domain  that  an  intelligence 
officer  has  to  deal  with.  The  contents  of  the  sample  reports  must  therefore  not  be  considered  as 
relevant,  they  were  construaed  solely  as  a  means  of  illustrating  the  techniques  involved.'.  We  have 
not  incorporated  geographical  aspects.  We  have  furthermore  restricted  the  number  of  sensors  to 
two,  being  human  observers  reporting  groups  of  sighted  vehicles  and  secondly  electronic  warfare 
units  reporting  radio-transmittals  perceived.  The  examples  used  will  therefore  be  admittedly 
simple,  but  suffice  to  illustfate  the  strength  of  the  combination  of  the  above  techniques. 

We  acknowledge  the  use  of  an  implementation  of  the  basic  ATMS  [DeKleer,  1986)  developed  at 
the  University  of  Twente,  The  Netherlantis,  listed  in  (Guoxing,  1989],  which  we  have  enhanced 
with  temporal  reasoning  facilities.  The  data  structure  used  as  the  foundation  for  the  temporal 
database  stems  from  [Dean  &  McDermott,  1987).  We  have  implemented  a  basic  forward  chaining 
production  system  as  described  in  [Merritt,  1989).  As  stated,  the  domain  is  hypothetical,  but  as 
guidelines  we  have  used  (VS  2-1351,  1988)  for  a  simple  order  -  *■  battle,  as  well  as  [VS  30-5, 
1989),  describing  combat  intelligence.  Stiuctured  Analysis  (I'outdon)  was  used  for  the 
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representation  of  the  process  structure.  Nijssen's  Information  Analysis  Method  (NIAM)  was  used 
for  the  representation  of  (he  data  structures.  The  application  was  developed  on  a  SUN  Sparc-2 
workstation  and  written  in  Quinnis  Prolog. 

We  will  first  address  the  domain  involved.  Then  we  will  provide  an  overview  of  the  application, 
d&>cribing  its  stnicture  and  specifying  the  user  interface.  Paragraph  3.4  will  detail  the  '.echniques 
used;  the  forward  chaining  algorithm  and  the  mie  format,  the  ATMS  arid  the  temporai  reasoning 
facilities  that  have  been  consuucted,  the  merger  of  the  latter  two,  and  the  data  fusior.  strategy. 

3.2  The  battlefield  environment 

3.2.1  The  area  of  intelligence  responsibility 

The  battlefield  environment  in  our  application  is,  as  indicated  in  the  previous  section,  kept 
relatively  simple  The  area  of  intelligence  responsibility  is  assumed  to  be  a  rectangular  area.  We 
have  divided  th'S  region  into  six  sectors,  each  having  the  same  dimensions  located, some  distance 
ahead  of  the  PLOT  (Front  Line  Own  Troops).  In  each  of  these  sectors  we  have  a  human  observer 
post  at  a  fixed  location,  the  central  point  of  the  sector.  These  observer  posts  (HI  to  H6)  report 
vehicles  sighted  passing  in  the  vicinity  of  their  locations.  The  reports  from  the  human  observers 
contain  the  position  (being  the  location  of  the  observer  post),  the  lime  of  sighting,  the  vehicle 
types  and  quantities  sighted  and  the  direction  of  movement. 

Apart  from  tlie  human  observer  posts  there  arc  two  comint  posts  at  the  own  side  of  the  PLOT. 
These  comint  posts  (part  of  an  EWU)  arc  assumed  to  provide  detailed  information  on  the  front 
sectors,  using  ESM  systems  for  the  interception  of  uansmissions  and  taking  bearings  to  determine 
the  positions.  They  are  able  to  provide  order  of  battle  information  based  6n  the  patterns  perceived 
in  the  intercepted  transmissions.  This  will  lead  to  the  inclusion  of  either  approximate  vehicle 
groups  or  a  reference  to  a  unit  type  in  the  comint  reports.  As  a  result  the  infomtation  reported  by 
the  comint  posts  is  less  reliable  han  the  information  reported  by  the  human  observers.  Beside  the 
position  the  comint  reports  contain  the  time  of  interception,  the  vehicle  types  and  quantities  or  a 
reference  to  a  unit  type. 

We  have  limited  the  spatial  aspects  in  the  application  to  a  minimum.  We  have  incorporated 
several  lime-dependent  context  parameters  to  describe  a  simplified  meteorological  condition.  This 
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entails  a  distinction  between  day  and  night,  between  clear  or  misty  circumitaiices,  and  specifically 
for  the  comint  repons  the  circumstance  that  the  inteceptions  of  transmissions  may  have  been 
subject  to  jamming,  possibly  causing  errors  in  content  and  reliability  of  the  comint  reports. 

3,2.2  The  order  of  battle 

The  basis  for  the  order  of  battle  is  taken  from  [VS  30-1,  1987),  however  we  have  adapted  this  to 
simplify  matters,  therefore  the  order  of  battle  used  should  not  be  matched  with  an  existing  one. 
The  top  level  unit  is  the  regiment.  The  regiments  can  be  either  a  tank  regiment  or  a  mechanized 
infantry  regiment. 


Tkreg 

3  Tkbat 

3  Tkemp 

3  Tkplt 

3  T80 

1  Mechinfbat_BMP 

'  3  Mechinfcmp_BMP 

‘  3  MechInfplt_BMP 

4  BMP 

1  AAAsect 

4  2SU 

1  Minesweepemp  ' 

3  Minesweepplt 

10  KMT 

Figure  3.1:  A  lank  regiment 

The  unit  types  are  tank  (Tk),  mechanized  infantry  (Mechinf_BTR,  Mechinf_BMP),  anti-tank 
(AT),  mine  sweeping  (MS),  artillery  (ARTY)  and  anti  air  artillery  (AAA).  As  vehicle  types  we 
have  tank  (T80).  armoured  cars  (BMP,  BTR),  anti-tank  (SA),  anti  air  artillery  vehicles  (ZSU), 
mine  sweeping  vehicles  (KMT),  trucks  caning  equipment  for  target  acquisition  (POLEDISH) 
and  heavy  artillery  vehicles  (2S3). 

The  mechanized  infantry  units  can  be  "mechinf_BMP"  or  ”mechinf_BTR",  depending  on  the 
vehicle  type.  The  main  force  of  the  regiments  consists  of  four  battalions.  A  battalion  consists  of 
several  companies  and  platoons.  We  assume  a  pre-combat  situation  some  distance  ahead  of  the 
PLOT,  implying  that  companies  will  generally  move  in  a  column  formation,  with  a  short  distance 
between  the  vehicles.  Generally,  the  companies  of  the  battalions  will  be  spread  out  across  the 
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breath  of  the  sectors,  the  companies  move  in  columns  of  platoons,  allowing  a  fast  deployment  if 
necessary. 


A  tank  regiment  has  three  tank  battalions  and  one  "mechinf_BMP"  battalion.  Also,  a  mine 
sweeping  platoon  is  added  to  the  regiment.  This  is  illustrated  in  figure  3.1.  The  numbers  listed  in 
the  figure  are  not  totals,  they  should  be  read  as  follows:  a  tank  regiment  has  three  tank  battalions. 
Each  tank  battalion  consists  of  three  tank  complies.  Each  company  in  turn  consists  of  three' 
platoons.  Finally,  a  tank  platoon  consists  of  three  T80's. 


Mechin£reg_BMP 

3  Mechinfbat_BMP 

3  Mechinfcnip_BMP 

3  Mechinfplt_BhP 
4  BMP 

1  Tkbat 

3  Tkcinp 

3  Tkplt 

3  T80 

1  AntiTkcmp 

9  SA 

1  ARTYsect 

1  TargetacqpJt 

3  POLEOrSH 

1  Mechartcmp 

9  2S3 

1  Minesweepplt 

10  KMT 


Figure  3.2:  A  mechanized  infantry  BMP  regiment 


There  arc  two  types  of  mechanized  infantry  regiment,  corresponding  with  the  vehicle  types  BMP 
and  BTR.  The  mechinf_BMP  regiment  consists  of  three  mechinf_BMP  battalions  and  one  tank 
battalion.  Beside  these  battalions  the  regiment  consists  of  an  anti-tank  company,  a  mine  sweeping 
platoon  and  an  artillery  section  with  target  acquisition  means  and  heavy  artillery.  The 
mechinf_BTR  regiment  consists  Of  three  mechinf_BTR  battalions  and  one  tank  battalion.  It  also 
has  an  anti-tank  company,  an  anti  air  artillery  section  and  a  mine  sweeping  platoon. 
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Mechinf  reg_BTR 

3  Mechinfbat_BTR 

3  Mechinfciiip_BTR 

3  Mechinfplt_8TR 
4  BTR 

,  1  Tkbat 

3  Tkcmp 

3  Tkplt 

3  T80 

1  AntiTkcmp 

9  SA 

1  AAAaect 

4  ZSU 

1  Minesweepplt 

10  KMT 


Figure  3.3;  A  mechanized  infantry  BTR  regiment 


3.3  System  overview 

3;3.1  The  structure  of  the  process 

The  overall  structure  of  the  application  is  as  follows;  we  have  a  domain  representing  a  simple 
battlefield  as  explained  in  the  previous  section,  with  sources  sending  in  reports  on  sighted  vehicle 
groups  and  perceived  radio-transmissions.  The  infonriation  in  the  reports  is  converted  into  unit 
structures.  By  default  each  report  is  first  assumed  to  refer  to  a  separate  unit  on  the  battlefield.  The 
further  structuring  of  the  units  is  accomplished  by  classifying,  correlating  and  aggregating  units 
by  the  application  of  rules  containing  knowledge  of  the  properties  of  the  domain  objects  and  the 
order  of  battle.  The  derivations  and  the  underlying  assumptions  concerning  these  units  and  their 
attributes  ate  passed  to  the  ATMS.  The  temporal  information  concerning  the  units  is  passed  to  a 
temporal  database.  The  rules  use  the  combination  of  information  contained  in  the  ATMS  and  the 
temporal  database.  The  top-level  process  structure  consists  of  the  following  functions; 


1.  Process  report; 

2.  Classify  unit; 

3.  Correlate  units; 

4.  Aggregate  units; 

5.  Process  ATMS-request; 

6.  Process  TDB-request. 
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The  functions  are  carried  out  in  response,  to  events,  being  requests  fiom  the  operator  of  the 
plication.  The  processing  of  a  report  is  the  conveision  of  a  report  into  a  unit  (the  assumption 
that  each  report  refers  to  a  separate  unit),  for  which  an  initial  "unit  frame"  is  constructed  with 
attributes  filled  in  as  much  as  possible  from  the  reported  infotmatioa  The  report  is  stored  as  a 
premise  in  the  ATMS,  a  timedist  entry  for  the  report  is  stored  in  the  temporal  debase  (TDB). 
The  unit  that  is  created  is  stored  in  the  ATMS  as  an  assumption.  Two  timedist  entries  are  stored  in 
the  TDB  (see  paragraph  2.2.3),  one  from  the  reference  point  to  the  begintime  (the  sighting  time 
reported),  and  one  from  the  begintime  to  the  endtime,  whereby  the  upper  bound  of  the  duration  is 
initially  set  to  infinity. 

The  three  main  phases  are  the  classification,  correlation  and  the  aggregation  of  units.  The 
classification  is  aimed  at  determining  the  unit  type.  A  classify  request  triggers  the  attempt  to 
classify  a  certain  vehicle  type  group  as  referring  to  a  specific  unit  type  by  the  application  of 
classification  rules.  The  result  is  stored  as  a  justification  in  the  ATMS  and  accompanying  timedist 
ent.ies  are  stored  in  the  TDB,  Among  the  cla.ssification  roles  are  default  rules,  which  also  derive  a 
unit  type,  but  the  latter  is  stored  as  an  assumption  in  the  ATMS.  The  assumed  unit  type  will 
possibly  be  used  later  to  correlate  and/or  aggregate.  When  new  information  indicates  that  the  unit 
is  not  a  tank  company  but  a  mechanized  infantry  company,  this  will  cause  a  recalculation  of  the 
ATMS  states  corresponding  to  the  validity  of  derived  statements  based  on  the  previous 
a.ssumption. 

The  correlation  of  reports  with  units  is  more  complicated.  Given  two  observer  posts  at  some 
distance  from  each  other,  it  is  possible  that  the  same  vehicle  groups  pass  both  observer  posts!  In 
the  case  of  intormation  from  electronic  warfare  units  this  may  hold  as  well  because  the  comini 
posts  may  report  rhe  same  group  morre  than  once.  The  correlation  is  aimed  at  eliminating 
duplicate  counts  of  the  same  units,  which  would  indicate  a  stronger  force  than  would  actually  be 
present  on  the  battlefield.  This  ph-tse  thus  encompasses  the  correlation  of  data  from  like  sensors  as 
well  as  from  different  sensors.  Correlation  rules  aid  in  detennining  whether  two  reports  in  fact 
refer  to  the  same  object.  When  this  occurs  the  unit  stroctruc  corresporiding  to  the  earlier  report  is 
clipped,  passed  to  the  ATMS  as  a  nogood  assumption,  uiggering  tiie  recalculation  of  the 
consistency  of  the  database. 

■Aggregation  is  the  combination  of  two  or  more  units  into  a  higher-level  unit.  When  an 
aggregation  takes  place,  the  resulting  unit  is  stored  separately,  leaving  the  units  used  for  the 


Aggregation  intact  because  there  may  be  several  options  for  the  aggregation  of  units,  and  units 
might  be  correlated  later  with  other  units.  Aggregation  niles  also  perform  a  classification  task 
because  they  will  derive  values  for  the  unit  type  of  the  resulting  aggregation. 

We  stress  that  the  control  of  the  application  is  to  a  large  extent  in  the  hands  of  the  operator.  We 
have  chosen  to  allow  the  phases  classification,  correlation  and  aggregation  to  be  initiated  by  the 
operator  and  not  by  the  application  itself.  This  implies  that  the  application  is  not  highly 
"automated".  The  reason  is  the  focus  on  techniques  for  truth  maintenance  and  temporal  reasoning; 
the  aim  was  not  to.  process  incoming  reports  in  real  time.  To  fiirtlier  support  the  interaction  with 
the  ATMS  and  the  TDB  a  direct  manipulation  of  the  ATMS-database  and  the  temporal  database  is 
possible  as  weU.  The  processing  of  requests  to  the  ATMS  and  the  TDB  are  contained  in  the  two 
remaining  functions  in  the  aforementioned  list.  In  paragraph  3.3.1  this  will  be  dealt  with  in  more 
detail. 

3.3.2  The  structure  of  the  data 

The  main  data  structures  in  the  application  are  "report",  "unit_type”  and  "unit".  The  ATMS 
further  uses  "tms_node”,  "assumption",  "justification"  and  "environment"  as  data  structures.  The 
temporal  databa.se  is  built  with  "timedist"  as  data  structure.  The  data  suuctures  will  be  ouUined 
below. 

The  report  contains  a  report  number  as  the  unique  reference,  and  the  source  of  the  report.  In  the 
case  of  a  human  observer  post,  the  location  of  the  sighted  vehicles  and  the  direction  they  were 
moving  in  is  reported.  The  vehicles  are  repotted  as  "sighted_vehicle_type _group",  represented  in 
the  database  as  tuples  of  vehicle  types  and  quantities.  In  the  case  of  a  comint  xport,  the  location 
and  orbat  information  are  reported.  In  both  cases  the  time  rf  sighting  is  contained  in  the  report 


Report_nr  ; 

1 

Source  type 

humint 

Source  nr  : 

3 

Direction  from: 

east 

Direction  to  : 

west 

Sight ing_tinie  : 

101 

Vehicle_group  : 

tSO  ,  9 

Figure  3.4: 
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The  "unit.typc"  is  the  representation  of  units  contained  in  the  standanl  order  of  battle.  A 
"uni^type"  is  represented  as  a  unit  class  and  unit  size.  e.g.  respectively  "tank”  and  "company”, 
implying  that  the  unit  type  is  a  tank  company.  This  distinction  is  made  because  it  may  for 
example  be  evident  what  class  a  unit  belongs  to.  but  not  what  the  size  of  the  unit  is.  The  following 
example  clarifies  the  representation  of  a  ”unit_typc": 

unit_type<inechinf_btr,cmp)  . 
unit_type (mechinf_btr,plt) . 

unit_type_group  {mechinf_btr,  ciiip,mechinf_btr,plt,  3)  . 
orbat_vehicle_type_group(!nechinf_btr,plt,btr,  4)  . 

The  "unit_type_group"  above  means  that  a  mechanized  BTR  infantry  company  (the  notation 
above  is  in  lower  ca.se  letters  due  to  a  convention  in  Prolog)  consists  of  3  mcchinf  platoons,  these 
in  turn  consisting  of  4  BTR  vehicles.  The  unit  type  data  is  used  in  the  rules.  In  effect,  a  niatch  is 
carried  out  between  the  "sighted_vehicle_type .groups"  contained  in  the  reports  and  the  "orbat- 
_vehicIe_type.groups''  of  the  known  order  of  battle  to  classify  the  unit  type. 


The  unit  is  the  central  data  structure,  it  contains  the  information  on  the  units  that  (are  assumed  to) 
exist  on  the  battlefield.  Apan  from  information  on  the  source(s)  that  reported  the  unit,  the  (last 
known)  position  and  direction  of  movement,  a  unit  fconsisLs  of  vehicle  type  groups  arxl  has  a  unit 
class  arid  a  unit  size.  The  vehicle  type  groups  may  be  the  result  of  several  sighted  vehicle  type 
groups  and  are  therefore  distinct  from  the  latter.  A  rating  is  attributed  to  the  unit  structure,  based 
on  several  context  parameters  concerning  the  time  of  day,  the  weather  and  jamming,  as  described 
in  paragraph  3.2.1. 


Unit_nr  :  1 

Source_type  ;  humint 

Source_nc  :  3 

La3t_j30Sition  :  [250,250] 
Sector  :  3 

Direction_f rom  :  east 

Direction_to  :  west 

Vehicle_groups  ;  [t80,9] 

Unit_class  :  tk 

Unit_3ize  :  emp 

Rating  :  a 

Figure  3.5:  Unit  structure 


The  ATMS  uses  four  main  data  structures.  The  following  are  based  on  the  ATMS-implementation 
in  Prolog  by  (Guoxing,  1989}  that  we  have  used,  which  will  be  addressed  in  paragraph  3.4.2: 

tm3_node (Index, Occasion, Status, Label, Justifications, Consequents, 
Rules, Nodetype) . 

assumption  (Index, Occasion, Epvironinentc)  . 
justification ( I ndex, Type , Consequent , Antecedents ) . 

!  environment (Index, N_assumptions, Assumptions, Nodes, Contradictory) . 

/ 

The  tmsjiode  data  structure  contains  first  of  all  an  index  at)d  the  occasion  it  corresponds  with. 
Furthennore,  the  status  of  the  node  (in  or  out),  a  label  representing  the  indices  of  environments 
(sets  of  assumptions)  in  which  the  ncxle  can  be  proven  using  all  justifications  ktwwh  to  the 
ATMS,  an  index  of  the  Justif1cation($)  describing  how  this  node  is  derivable  from  other  trades,  an 
'  index  for  the  justifications  using  this  node  as  an  antecedent,  a  Rules  field  reserved  for  the  problem 
solver  and  finally  the  type  of  node  (assumed  node,  premise,  or  derived  node). 

The  assumption  data  struaure  has  the  occasion  as  second  argument,  and  provides  a  list  of  the 
environments  wherein  the  assumption  holds. 

The  justification  data  structure  lists  the  t^  of  justification  (supplied  by  the  problem  solver),  the 
index  of  the  consequent  node  and  the  indices  of  the  antecedent  nodes. 

The  data  structure  environment  includes  the  number  of  assumptions  in  this  environment,  the 
(indices  of  the)  assumptions  themselves,  the  nodes  in  whose  label  the  environment  appears,  and 
the  field  contradictory  indicates  whether  this  environment  is  inconsistent 

We  have  used  a  temporal  data  structure  that  we  call  timedist  that  originates  from  [Dean  & 
McDermott,  1987]  as  the  data  structure  for  the  temporal  database.  The  data  structure  contains  the 
names  of  the  begin-  and  the  endpoint  and  the  lower  and  upper  bounds  of  the  duration  between  the 
begin- and  endpoint: 


timedist  (Beginpoint, Endpoint,  Low,  Higti)  . 
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The  temporal  representation  implies  that  nothing  is  deleted  from  the  database.  All  data  stored  in 
the  ATMS  and  in  the  internal  (Prolog)  database  receives  a  temporal  entry.  In  the  case  that  an 
occasion  is  no  longer  valid,  the  temporal  entry  is  clipped,  but  the  occasion  as  well  as  the  clipped 
temporal  entry  are  retained. 

3.3.3  The  structure  of  the  dialogue 

In  its  current  form,  the  application  consists  of  a  main  program  containing  the  forward-chaining 
engine,  predicates  governing  temporal  reasoning,  the  interaction  with  the  ATMS  and  the  TDB, 
and  the  definition  of  the  interface.  Furthermore,  there  are  separate  files  containing  the  ATMS,  a 
compiled  report  database,  a  compiled  domain  database  and  a  compiled  roles  luiowledge  base.  The 
Prolog  database  is  used  as  the  working  storage  means.  Due  to  the  rroncentration  on  techniques 
involving  troth  maintenance  and  temporal  reasoning,  we  have  not  incorporated  any  graphical 
facilities  whatsoever. 

The  control  of  the  application  is  to  a  targe  extent  in  the  hands  of  the  operator.  The  main  menu 
therefore  corresponds  with  the  functions  described  in  paragraph  3.3.1  and  has  the  following  form; 

1 .  Report  generator 

2.  .  Classify  report 

3.  Correlate  units 

4.  Aggregate  units 

5.  ATMS  request 

6.  TOB  request  ‘  . 

7 .  Exit 

The  report  generator  can  be  called;  it,  fetches  and  prints  reports  one  by  one: 

Generate  report?  ty/n] :  y. 

Report_nr  :  5 
Source_type  :  humint 
Source_nr  :  3 
Direction_f roin;  east 
Direction_to  :  west 
Sighting_time  :  105 
Vehicle_group  :  btr  ,  3 
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For  i»ch  report,  a  new  unit  is  asserted  with  as  yet  no  unit  class  or  unit  size,  but  with  vehicle  ty; . 
groups  fllled  in  if  these  were  reported.  Transparent  to  the  user,  corresponding  occasions  and 
temporal  entries  are  passed  to  the  ATMS  and  the  TDB. 

Gassification,  concladon  and  aggregation  are  all  initiated  by  the  operator.  A  request  results  in  the 
application  of  rules.  The  application  of  the  rules  is  sequential,  stepping  through  the  rules  in  the 
order  in  which  they  are  contained  in  the  knowledge  base.  It  is  possible  to  fire  applicable  rules  one 
at  a  time  or  all  at  once.  The  inference  mechanism  and  the  rule  fomnat  will  be  addressed  in 
paragraph  3.4.1.  When  a  rule  fires  this  is  communicated  to  the  user,  stating  the  rule  that  was  fired 
and  the  interactions  with  the  ATMS  artd/or  the  TDB  that  resulted  from  it. 

Apart  from  the  above  a  direct  interaction  with  the  ATMS  and  the  TDB  is  possible.  The  ATMS 
database  can  be  queried  for  tms_nodes,  assumptions,  justifications  and  environments.  It  is 
possible  to  additionally  pass  instantiations  of  these  structures  to  the  ATMS,  providing  direct 
control  over  the  ATMS,  The  temporal  database  can  be  queried  and  timedist  instantiations  may  be 
asserted.  However,  the  interaction  with  the  ATMS  and  the  TDB  will  generally  be  triggered  by  the 
application  of  the  rules.  The  details  of  the  interaction  will  be  further  dealt  with  in  paragraphs 
3.4.2.  and  3.4.3. 

We  will  indicate  the  flow  of  control  between  the  main  functions.  The  functions  initiated  by  the 
main  menu  can  be  called  independently,  however,  they  do  depend  on  each  other.  The  report 
generator  wiU  generate  reports  one  at  a  time.  A  unit  frame  is  constructed  for  the  report  and  filled 
in  with  the  report  information.  The  report  generator  will  ask  whether  more  reports  are  required.  In 
general,  when  a  number  of  reports  have  been  generated,  the  functions  classification,  correlation 
and  aggregation  are  called  sequentially.  This  is  illustrated  in  figure  3.8  below.  From  each  of  these 
phases  the  report  generator  can  be  called  again,  after  which  the  above  process  is  repeated. 

During  the  four  phases  above  the  ATMS  and  the  TDB  are  inspected  and  adapted  continuously  by 
the  system,  triggered  by  the  rules  that  are  fired.  However,  this  inaction  and  adaptation  may  take 
place  manually  as  well. 


Figure  3.6: 


Control  flow 
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3.4  Technology  overview 

3.4,1  Forward  chaining  production  system 

We  have  used  a  simple  forward  chaining  production  system  for  the  implementation  of  the  rule- 
application.  The  algorithm  is  taken  from  (Merritt,  1989).  It  is  a  basic  failure-driven  loop  carrying 
out  a  "ir.atch-and-process"  cycle,  firing  all  rule-instantiations,  one  rule  at  a  time. 

We  have  chosen  to  use  a  forward-chaining  rule-firing  strategy  for  the  fusion  of  information  from 
the  reports.  Rule-ba-sed  reasoning  is  a  widespread  technique  and  it  provides  a  quite  natural 
representation  for  sta:.ng  e.g.  some  simple  heuristics  pertaining  to  order  of  battle.  The  forward- 
chaining  strategy  was  also  chosen  because  reports  are  entered  one  by  one  and  continuously  and 
the  information  that  feeds  the  rules  becomes  available  in  bits  and  pieces.  This  as  o[)posed  to  for 
instance  the  domain  of  diagnosis',  where  a  set  of  symptoms  is  entered  at  once,  and  a  backward 
chaining  strategy  is  used  that  finds  the  rule(s)  containing  the  diagnosis  that  best  matches  the 
symptoms.  Also,  the  ATMS  cannot  store  variables  ,  and  thus  all  ATMS  nodes  must  be 
instantiations  of,  in  our  case,  Prolog  clauses.  This  implies  that  a  backward-chaining  rule-firing 
Strategy,  whereby  instantiations  ate  only  "vinual"  in  the  sense  that  they  ate  not  explicitly  stored, 
docs  not  suffice. 

The  rule  fonnai  that  we  have  used  is  as  follows: 

rule (Rule_type,Rule_nr, Description) : : 

[Conditionl, 

Condition2,  etc) 

, [Actionl, 

Action2,  etc) . 

A  simple  example  pf  a  nrle  is  the  following,  stating  that  a  Unit  is  classified  as  being  a  tank 
company  when  the  unit  consists  of  between  S  and  13  tanks.  The  '’derive_and_assume"  statement 
is  a  call  to  the  ATMS,  triggering  the  passing  of  a  justification  for  the' unit  cla.'S  and  unit  size 
classification  to  the  ATMS. 
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rule  (classify '(Unit_nr)  ,5,tlccnip)  ; : 

[tins  (unit_vehicle_type_group(Unit_nr,t80,Qty) ) , 

Oty  >8, 

Qty  <13 

1 

— > 

t tempera l_di3tance (ref , end (unit (Unit_nr) ) , Low,_High) , 
derive_and_assume (unit_clas3 (Unit_nr, tk) Low) , 
derive_and_assume (unit  size (Unit_nr, emp) Low) 

)  •  ,  ' 

The  rule  types  are  divided  into  classification,  correlation  and  aggregation  rules.  The  above  rule  is 
an  example  of  a  classification  rule. 

The  derived  unit  class  and  unit  size  ate  set  to  be  an  assumption  in  the  ATMS  after  being  passed  as 
a  derivation.  This  implies  that  if  at  a  later  time  the  unit  class  or  unit  size  of  this  unit  are  derived  to 
be  something  other  than  ''tk”  and  "emp",  the  passing  of  the  assumption  as  a  "nogood"  to  the 
ATMS  will  result  in  tracking  the  conclusions  that  have  since  made,  based  in  part  on  the 
assumption  that  the  unit  was  a  tank  company. 

The  conditions  and  acuons  of  the  rules  are  contained  in  lists,  enabling  eftlcient  processing  in 
Prolog  We  distinguish  between  three  types  ot  "calls"  in  the  conditions  and  actions  of  the  rules.. 
These  can'  be  calls  to  f^olog,  calls  to  the  ATMS  and  calls  to  the  temporal  database.  These  three 
types  of  calls  are  the  building  blocks  of  the  rules  They  are  carried  out  by  "match"  and  "process" 
clauses,  which  u.se  predicates  corresponding  to  the  calls.  The  Prolog  calls  may  be  calls  to 
functions  in  the  main  program,  queries,  as.sertions  and  retractions  of  clauses  in  die  Prolog 
database,  as  well  as  built-in  Prolog  predicates.  The  interaction  with  the  ATMS  and  the  use  of  the 
temporal  database  will  be  the  subject  of  the  next  section. 
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3.4.2  Truth  maintenance  and  temporal  reasoning  in  Mefisto 

3.4.2. 1  Keeping  track  of  reason 

We  have  used  an  implementation  of  the  ATMS  that  is  listed  in  [Guoxing,  1989],  written  in 
Prolog.  De  Kleer's  original  ATMS  does  not  incorporate  negations,  nor  disjunctioas,  nor  does  it 
allow  to  explicidy  contain  default  justifications.  The  implementation  of  the  ATMS  of  [Guoxing, 
1989]  concerns  the  basic  ATMS  and  therefore  does  not  include  these  either.  Instead  of  a  time- 
consuming  adaptation  of  Guoxing's  implementation,  we  have  chosen  to  bring  negations, 
disjunctions  and  defaults  into  the  iraeraction  with  the  ATMS  triggered  by  the  application  of  the 
rules,  letting  the  problem  solver  deal  with  them.  An  adaptation  of  Guoxing's  implementation  was 
necessary,  however,  to  remove  several  errors  mainly  concerning  the  subsumption  of  environments 
and  the  allocation  of  contradictory  environments  as  a  result  of  passing  nogood  assumptions. 
Further  adaptations  concerned  the  interaaion  with  the  main  program  and  the  temporal  database. 
Details  can  be  found  in  the  appendices.  . 

The  consultation  and  manipulation  of  the  ATMS  is  triggered  by  the  application  of  the  rules;  the 
ATMS-calls  as  explained  in  the  previous  paragraph.  The  ATMS  is  queried  in  the  conditions  of  the 
rules.  For  instance,  in  the  case  of  the  following  condition,  used  in  the  example  of  the  previous 
paragraph: 

tins  (unit_vehicle_type_group(Unit_nr,t80,Qty) ). 

The  possible  ATMS-calls  are  the  foOowing: 

asktms (X, Status) . 
add_premi3e(X) . 
add_as3uinption<X)  . 

add_justi£icatlon (Conseiroent.AntecedentLiat) . 

pa33_nogood(X) . 

An  occasion  can  be  asserted  as  a  premise.  A  ne*?'  rripiior  car:  ereatrsf  rewthins'  is 
assertion  of  an  assumed  node  in  the  ATMS,  v  (jv-  crttaiiss  sf  a 

environment.  Justifications  pass  derived  nodes  to  ’'ft?',  Whes  passio? 

an  assumption  or  set  of  assumptions  as  a  nog(X)d  envtr'.f’frseftf  te  ise  aTiVR  the  envirptTOefs  is 
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set  to  "contradictory",  triggering  a  recomputation  of  the  labels.  The  ATMS  checks  which  iKxles 
have  labels  containing  environments  that  are  subsumed  by  this  nogood  environment  It  changes 
these  environments  to  "contradictory"  as  well  and  adjui„>  the  labels,  so  that  these  nogoods  are 
removed  from  the  respective  labels.  If  u  a  result  the  label  becomes  empty,  the  status  of  that  node 
is  set  to  oLt,  the  node  is  no  longer  valid.  This  process  results  in  an  "outlist",  i.e.  a  list  of  the  nodes 
that  the  ATMS  has  set  to  out. 

3.4.2.2  Keeping  up  with  time 

Each  occasion  has  a  timcdisi  mtry  representing  the  duration  of  the  occasion.  We  repeat  the  basic 
temporal  data  structure  here: 

timedist (begin (Occasion) ,end(Occasion) , Low, High) . 

This  repre.sents  that  the  duration  of  Occasion  is  known  to  have  a  lower  bound  Low  and  an  upper 
bound  High.  This  is  a  relative  duration,  not  related  to  an  absolute  reference  point.,  In  the  case  that 
the  begintime  c  f  the  occasion  is  known  as  well,  another  timedist  entry  is  asserted  into  the 
temporal  database  to  allow  the  calculation  of  absolute  time.  We  have  chosen  this  absolute 
reference  point  (ref)  to  be  the  timepoint  0.  This  second  timedist  entry  represents  the  begintime  of 
the  occasion  and  will  have  both  lo'-  er  and  upper  bound  equal  to  the  begintime  of  the  occasion. 
For  a  persistence,  the  endtime  in  the  abo^c  timedist  entry  is  set  to  infinity,  indicating  that  the 
occasion  is  believed  to  be  valid  indefinitely,  to  be  defied  only  by  information  stating  the  contrary. 

The  interaction  in  the  rules  allows  to  query  the  temporal  database,  calling  functions  that  calculate 
temporal  distances,  asserting,  updating  and  clipping  timedist  entries.  The  following  calls  to  the 
temporal  database  are  possible: 

tiniedi3t(X,Y,Low,High)  .■ 
add_t imedist (X, Y, Low, High) . 
updat't_timedi3t  (X,  Y,Lo-~,High)  . 
clip_node (A,T) . 
clip_nodel'r;-,  (List,T)  . 
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The  clipping  mechanism  changes  persistences  into  clipped  persistences  (clips)  'vhen  called  for. 
This  clipping  is  essentially  the  replacement  of  the  upper  bound  of  the  occasion  to  be  clipped.  Due 
to  the  relative  notions  involved  in  the  timcdist  entries  the  new  upper  bound  will  be  the  difference 
between  the  cliptime  and  the  begintime  of  the  occasion.  Let's  take  the  following  example: 

tiniedist  (ref  .begin  (unit  (1) ),  120, 120)  . 
timedist (begin (unit (1) ) ,end(unit (1) ) ,  0,  inf) . 

When  the  occasion  unit(l)  is  clipped  at  time  200.  the  result  of  the  clipping  will  be  that  the  first 
timedist  entry  is  kept  intact  and  that  the  second  timedi.st  entry  is  updated  to  the  following: 

timedist (begin (unit (1) ) ,end(unit (1) ) , 80, 80) . 

When  querying  the  temporal  distance  from  the  reference  point  ref  to  end(unit(l))  the  result  will 
now  be  2(X), 

We  have  furthermore  implemented  an  elaborate  collection  of  temporal  queries.  The  queries  enable 
to  determine  whether  a  certain  timepoint  comes  before  another  timepoint.  whether  an  occasion  is 
true  throughout  a  specific  interval,  whether  two  occasions  are  overlapping,  etc.  We  refer  to  the 
appendices  for  a  more  complete  list. 

3.4.3  Inference  and  temporal  truth  maintenanc 

Given  techniques  for  assumption-based  truth  maintenance  and  temporal  reasoning,  the  question 
now  arises  how  to  combine  them.  Both  the  temporal  data  structure  and  the  representation  of  an 
occasion  in  an  ATMS  contain  infotmation  concerning  the  validity  of  an  occasion.  The  ATMS  is 
used  to  keep  uack  of  assumptions  and  conclusions  based  on  these  assumptions.  The  temporal 
database  must  be  updated  when  the  ATMS  has  defied  earlier  derived  conclusions.  The  ATMS 
in/out  truth  status  represents  the  current  status  of  an  occasion  in  the  sense  that  it  happens  to  be  the 
result  of  the  latest  adaptation  to  the  ATMS,  but  it  is  in  fact  time-indeijendent.  The  temporal 
database  represents  the  complete  period  during  which  the  occasion  is  valid.  The  combination  is 
comparable  to  a  four-dimensional  space-time  representation,  in  the  sense  that  it  allows  to 
represent  the  state  of  the  battlefield  (which  is  described  by  the  occasions)  at  each  moment  in  time. 
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Moreover,  it  does  not  represent  just  one  state,  but  impIiciUy  contains  a  multitude  of  states  due  to 
the  representation  based  on  as.sumptions. 

The  effeauation  of  the  combination  of  truth  maintenance  and  a  temporal  database  is  triggered  by 
the  application  of  the  rules.  Adaptations  to  the  implementation  of  the  ATMS  of  [Guoxing,  1989] 
were  made  to  effect  the  passing  of  information  to  and  from  the  ATMS,  necessary  to  be  able  to 
adapt  the  timedist  entries  when  an  environment  is  passed  as  "nogood”  to  the  ATMS.  When  an 
occasion  is  passed  to  the  ATMS,  at  least  one  timedist  entry  is  asserted  to  the  temporal  database,  as 
outlined  in  previous  paragraphs.  When  an  assumption  or  set  of  assumptions  is  passed  as  a  nogood 
environment  to  the  ATMS  the  timedist  entries  for  the  assumptionfs)  are  adapted  simultaneously, 
clipped  by  some  oliptime.  The  ATMS  tenims  a  list  of  the  nodes  invalidated  as  a  result  of  the 
ensuing  label  rccompiitation.  These  nodes  can  then  be  clipped  accordingly. 

To  accomplish  the  above  we  have  implemented  a  set  of  predicates  that  combine  the  lunaions 
listed  in  ne  previous  two  paragraphs.  Ttie.se  arc  used  in  the  actions  of  the  rules  and  are  the 
following,  the  relevant  source  code  for  the  predicates  listed  below  is  contained  in  Appendix  A: 

asktms (X, Status ) . 
addi_premise(X,T)  . 
assume (X, T) .  , 

derive (X, List , T) . 
derive_and_a3sume(X,List,T) . 
replace_riode(X,y)  . 
set_node  (X, Status) . 
add_timedist  (X,Y, Low, High) 
update_timedist (X,Y, Low, High) . 
clip_node (X, T) . 
clip_nodeii3t (List,T) . 
pass_nogood(X,0utLi3t) . 
set_nogood(X,T) . 

These  perform  selections,  additions,  updates  and  "deletions",  the  latter  in  effea  the  replacement 
of  (truth)  status  in  by  stanis  out.  A  derived  occasion  results  in  passing  a  justification  to  the  ATMS 
with  the  nodes,  that  were  used  as  conditions  in  the  rule,  as  the  antecedents  of  this  justification.  It 
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is  also  possible  that  a  derived  occasion  u;  set  to  be  an  assumption  as  well,  a  feature  intended  to 
allow  the  tracking  of  how  defaults  were  derived  (e.g.  when  assuming  unit  types)  which  is  not 
incorporated  in  the  basic  ATMS.  A  node  can  be  replaced,  or  set  to  another  truth  status.  The  set 
nogood  predicate  is  a  combination  of  "pass  nogood”,  "clip  node”  and  "clip  nodelist”.  The  clipping 
of  a  nogood  assumption  results  in  the  passing  back  of  a  list  of  the  nodes  set  to  out,  the  "clip 
nodelist”  predicate  carries  out  the  clipping  of  this  list. 

We  will  illustrate  the  above  for  the  example  that  was  already  contained  in  chapter  2  for  the  four 
occasioas  occl  to  occ4.  We  instantiate  occl  as  a  premise  from  timepoint  0  on,  and  occ2  as  an 
assumption  from  timepoint  100  on: 

I  ?-  add_premise (occl, 0) , 

I  ?-  add_a3suinption(occ2,100)  . 

The  ATMS  now  contains  two  nodes,  a  justification  for  the  assumption  occ2.  as  well  as  an 
environment  consisting  of  the  assumption.  Now.  we  will  apply  two  mies,  resulting  in  the 
derivation  of  occasions  occ3  and  occ4.  The  occasion  occ3  is  for  example  the  result  of  firing  the 
first  rule  below.  The  rule  states  that  occ3  is  derived  if  occl  and  occ2  are  valid  in  the  ATMS.  The 
derive  statement  adds  occ3  as  a  derived  node  to  the  ATMS,  and  simultaneously  adds  occ3  to  the 
temporal  database,  with  a  begintime  corresponding  to  the  later  of  the  begintimes  of  occl  . and  occ2 
(application  of  the  rule  will  find  this  to  be  the  tirnepoint  1(X)). 

rule (example, l,occ3) : : 

[tms(occl), 

tm3(occ2)) 

mm> 

[later (occl, occ2, Time) , 
derive(occ3,_,Time) 1 

The  second  rule  results  in  the  derivation  of  occ4.  It  is  instantiated  in  the  ATMS  as  a  derived  ixxte, 
derived  from  the  validity  of  the  earlier  derived  occ3.  As  the  begintime  for  occ4  the  begintime  of 
,occ3  is  taken,  the  latter  being  calculated  by  the  temporal  distance  (iiause  contained  in  the  rile. 
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ri'le  (example,  2,  occ4)  : :  '  ' 

[tms (occ3) ] 

— > 

[temporal_distance(ref,end(occ3) ,Time,_) , 
derive (occ4,_,Time) ) 

The  following  is  the  result  of  firing  the  niles: 

”>  fire (example, _) . 

Adding  justification  for:  occ3 

Starting  at  time:  100 

Rule,  fired:  example,  1,  occ3 

Fire  rule?  y. 

Adding  justification  for:  occ4 

Starting  at  time:  100 

Rule  fired:  example,  2,  occ4 

The  ATMS  can  be  consulted  for  lists  of  the  nodes,  justifications  and  environments  contained  in 
the  ATMS.  When  we  inspect  the  justifications  the  ATMS  has  constructed  due  to  the  firing  of  the 
two  rules  above,  the  result  is  the  following; 

Justification:  2  ->  Type:  example 
Consequent  :  3 
Antecedents  :  [1,2] 

Justification:  3  ->  Type:  example 
Consequent  :  4 
Antecedents  :  [3] 

The  first  justification  listed  means  that  a  justification  has  been  added  with  "Type"  indicating  the 
rule  type  that  caused  the  justification.  The  consequent  of  the  justification  is  node  3,  the 
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antecedents  are  nodes  I  and  2.  For  this  example,  the  numbers  of  the  nodes  correspond  with  the 
numbers  of  the  occasions,  as  the  list  betow  wiU  show.  This  also  illustrates  the  "bookkeeping” 
nature  of  the  ATMS;  the  derivations  are  registered  without  any  reference  to  the  meaning  of  the 
tKxles  involved.  The  second  justification  above  corresponds  to  the  derivation  resulting  from  the 
second  rule. 

Now,  when  we  inspect  the  ATMS  for  the  nodes  with  truth  status  in,  the  following  list  is 
generated: 


1  1- 

tell. 

_node ( 

in)  . 

Node 

1: 

occl. 

premise 

node 

Node 

2: 

occ2. 

assumed 

node 

Node 

3: 

occ3. 

derived 

node 

Node 

4: 

occ4. 

derived 

node 

The  internal  representation  of  these  nodes  in  the  ATMS  further  contains  the  label,  being  the  set  of 
environments  that  the  node  is  valid  in.  FOr  examine,  we  will  list  the  representation  for  node  3 
here: 


Node  : 

3  ->  Datum;  occ3 

Status : 

in ' 

Label  : 

Just  : 

[2J 

Cons  ; 

[3] 

Type  : 

[derived! 

This  implies  that  occ3  is  contained  in  the  ATMS  with  envimnmera  1  as  label.  In  our  example, 
there  is  only  one  enyirorunent,  containing  the  assumption  occ2.  The  field  "Just"  contains 
justification  2  as  the  justification  that  instantiated  occ3,  and  the  field  "Cons"  states  that 
justification  3  contains  node  3  as  an  antecedent 

The  clipping  of  nodes  is  also  instigated  by  the  application  of  rules.  We  will  use  the  following 
clipping  rule  which  does  not  contain  any  conditions,  as  these  are  not  relevant  here.  The  condition 
would  be  some  state  that  would  lead  to  the  clipping  of  the  assumption  occ2  at  timepoint  190. 
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The  nile  is  as  follows; 

rule (clipping, 1, occ2) : : 

n 

[set_nogood(oec2,190)] . 
I  ?-  fir,e(clipping,  1)  . 

Setting  nogood:  occ2 


t 

i  '  I 


Nodes  set  to  out  by  ATMS  are: 
occ2,  clipped  at  time  190  , 

occ3,  clipped  at  time  190 

occ4,  clipped  at  time  190 

Rule  fired:  clipping,  1,  occ2 

The  nodes  corresponding  wiih  occ2,  oc3  and  occ4  are  set  to  out  in  the  ATMS,  environment  1 
above  is  set  to  "contradictory",  and  a  justification  is  added  for  the  nogood  assumption  added  to  the 
ATMS.  When  we  query  the  absolute  temporal  bounds  for  the  occasions  the  result  is  the  following: 


I  ?-  time(_)  . 

[occl, 0, inf] 

[occ2, 100,190] 
iocc3,100,190] 

(occ4, 100, 190] 

When  we  ask  which  nodes  have  truth  status  in,  the  ATMS  responds  as  follows: 

I  ?-  tell_node (_, in) . 

Node  1:  occl,  premise  node 

An  issue  is  what  to  pass  to  the  ATMS.  If  all  data  that  is  usually  stored  in  databases  is  now  stored 
in  an  ATMS,  not  considering  their  meaning,  the  overhead  might  not  be  worthwhile.  Moreover,  the 
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nature  of  an  ATMS  is  that  it  perfonns  bookkeeping,  it  keeps  track  of  how  the  nodes  were  derived 
and  thus  why  something  is  valid  or  not  The  problem  solver  keeps  track  of  what  it  means  and 
when  it  is  valid.  The  representation  of  semantical  content  in  an  ATMS  is  therefore  a  waste  of 
resources.  For  this  reason  the  timedist  entries  are  kept  outside  the  ATMS.  Secondly,  the  timedist 
entries  implicitly  represent  the  validity  of  occasions  and  storing  them  in  the  ATMS  database 
would  entail  redundancy,  leading  to  integrity  problems.  The  ATMS  needs  only  explicitly  contain 
the  occasions  as  nodes.  In  this  way,  the  ATMS  keeps  track  of  the  occasions,  but  the  history  of  the 
occasion  is  not  represented  in  the  ATMS. 

3.4.4  Data  fusion  in  Mefisto 

In  paragraph  3.3  the  main  functions,  data  structures  and  flow  of  control  in  Mefisto  were  outlined. 
Here  we  will  indicate  step  by  step  what  actions  can  be  taken  in  the  application  to  perform  the 
fusion  of  refwned  information. 

The  strategy  for  perfonning  data  fusion  is  governed  by  the  four  main  phases  that  we  will  repeat 
here:  .  , 

1 .  Generation  of  reports; 

2.  Classify  unit  types  from  report  information; 

3.  Correlate  (seemingly)  identical  units; 

4.  Aggregate  units  into  higher  level  unit  structures. 

The  first  phase  is  the  generation  of  reports.  When  the  report  generator  is  called  to  generate  a 
report  the  first  action  taken  is  the  construction  of  a  unit  strucnite  as  described  in  paragraph  3.3.2. 
This  unit  structure  is  filled  in  as  much  as  possible  and  a  reference  to  the  report  is  made  to  enable 
tracing  the  reported  information.  We  stress  that  this  is  an  intermediate  structure,  resulting  from  the 
underlying  assumption  that  each  report  refe.s  to  a  separate  unit  on  the  battlefield.  These  unit 
structures  may  be  altered  or  eliminated  in  the  later  correlation  phase. 
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The  unit  stmcture  contains  the  following  separate  elements: 
unit ( Jnit_nr) . 

origin (Unit_nr, Source_type, Source_nr, Report_nr) . 
la3t_ltnown_niovement  (Unit_nr,  Position,  Sector,  Direction)  . 
unit_vehicle_type_group (Unit_nr, Vehicle_type, Quantity) . 
unit_clas3  (Unit_nr,l'nit_class)  . 
unit_3ire(Unit_nr,U'iit_si2e)  . 
rating(Unit_nr, Rating) . 

The  ''unit_vehicle_type_group"  may  be  repeated  if  the  unit  consists  of  more  than  one  vehicle  type 
group.  An  occasion  for  the  report  is  passed  to  the  ATMS  as  a  premise,  a  timedist  entry  for  the 
report  (sighting  time)  is  asserted  to  the  temporal  database.  An  occasion  for  unitCUnit_nr)  is  passed 
to  the  ATMS  as  an  assumption.  The  unit  class  and  unit  size  (together  the  unit  type)  will  not  be 
filled  in  yet.  The  unit  vehicle  type  group(s)  is  (are)  adopted  from  the  report  The  unit  vehicle  type 
groups  are  passed  to  the  ATMS  as  assumptions  as  well.  The  reason  is  that  the  reported  sightings 
are  not  at  first  hand  assumed  to  be  compleielj  reliable.  The  occasions  are  passed  to  the  temporal 
database  as  persistences.  This  implies  that  two  timedist  entries  are  asserted  to  the  temporal 
database.  The  first  registers  the  begintime  of  the  occasion,  the  second  registers  the  duration  of  the 
occasion  with  the  upper  bound  set  to  infinity,  as  explained  in  paragrapth  3.4.2. 

The  second  phase  is  the  classification  of  unit  types.  The  unit  structures  resulting  from  the  reports 
must  now  be  attributed  with  a  unit  class  arid  a  unit  size.  This  is  accomplished  by  the  application  of 
classification  rules.  These  clas.sification  rules  contain  knowledge  on  the  order  of  battle,  starting  at 
the  vehicle  level.  For  instance,  a  report  from  a  human  observer  of  a  colurrm  often  tanks  will  be 
classified  as  referring  to  a  tank  company.  Oassification  will  often  take  place  on  the  basis  that  a 
specific  vehicle  type  or  group  of  vehicle  types  is  characteristic  for  a  certain  unit  type.  Alsj,  the 
absence  of  a  certain  vehicle  type  may  indicate  values  for  unit  class  and  possibly  size.  The 
occasions  for  the  unit  class  and  size  are  passed  as  "derived  assumptions"  to  the  ATMS,  allowing 
that  they  may  be  set  to  nogood  at  a  later  time.  The  timedist  entries  for  unit  class  and  size  will  be 
adopted  from  the  timedist  entries  of  the  unit  structures. 

The  third  phase  is  correlation.  The  aim  is  to  distinguish  references  to  the  same  battlefield  unit  by 
various  reports  and  to  unite  the  reported  information  into  orte  unit  structure.  Here,  the 
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intermediate  unit  stniaures  resulting  from  the  report  generation  are  inspected  and  duplicate 
references  to  the  same  battlefield  objects  are  eliminated,  if  possible.  Correlation  therefore  requires 
criteria  to  eliminate  duplicate  counts.  The  criteria  are  applied  by  correlation  nileis. 

Important  is  that  criteria  are  used  to  perfonn  the  correlation  of  like-sensor  data  as  well  as  for  the 
correlation  of  data  from  different  sensor  types.  In  our  application,  this  means  both  data  reported 
by  human  observers  (humint)  and  data  from  electronic  warfare  units  (comint).  The  strategy  we 
have  chosen  for  correlation  is  that  we  correlate  like-sensor  data  first,  data  from  different  sensor- 
types  after  that.  Secondly,  we  restrict  the  correlation  to  be  applied  pairwise.  We  will  illustrate  this 
for  the  case  that  four  reports  refer  to  the  same  battlefield  unit.  Let’s  assume  that  the  unit  stnictures 
resulting  from  these  reports  are  called  Uj  to  U4.  The  first  three  ate  humint  reports,  the  last  cne  is  a 
comint  report  Application  of  the  correlation  rules  will  result  in  a  sequence  of  three  correlations; 
U]  with  U2  (result  Ujj).  U12  with  U3  (result  U123).  and  finally  U]23  with  U4,  resulting  in  U]234.  The 
strategy  of  pairwise  correlation  restricts  the  complexity  in  the  correlation  rules.  More  importantly, 
it  will  also  restrict  the  computational  complexity  as  the  number  of  occasions  grows.  We  stress 
here  again  that  we  use  the  term  correlation  for  attributing  reported  information  to  battlefield 
objects  already  sighted,  not  as  the  correlation  of  low  level  sensor  tracks. 

The  correlation  of  two  unit  structures  will  result  in  the  clipping  of  the  earlier  unit  structure.  The 
later  unit  structure  (the  result  of  a  later  report)  is  kept.  Attributes  of  the  later  unit  structure  may  be 
filled  in.  for  example  when  correlating  a  humint  sighting  with  an  earlier  comint  report  the 
frequency  will  be  added  to  the  unit  structure  that  resulted  from  the  humint  sighting.  Also,  the 
vehicle  type  groups  may  be  adapted  to  incorporate  the  information  from  both  reports.  Generally, 
correlation  will  imply  an  accumulation  of  information  concerning  battlefield  objects.  In  this  way, 
the  units  "rhove  ahead"  on  the  battlefield,  so  to  speak.  The  earlier  unit  structure  is  passed  as  a 
nogood  assumption  to  the  ATMS.  This  may  lead  to  the  situation  that  conclusions  based  on  the 
existence  of  this  earlier  unit  ate  set  to  out  by  the  ATMS.  The  unit  is  clipped  in  the  temporal 
database. 

The  last  phase  is  the  aggregation  of  units.  The  units  remaining  after  the  correlation  phase  are  input 
to  the  aggregation  phase.  The  aggregation  is  aimed  at  grouping  units  into  higher  level  units. 
Platoons  are  combiiicd  into  companies,  com[>anies  will  in  turn  be  aggregated  into  battalions, 
battalions  into  regiments.  Aggregated  units  are  represented  separately  in  the  ATMS.  The  reason 
we  keep  them  apart  is  that  units  may  be  part  of  more  than  one  aggregation,  therefore  the  single 
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units  remain  in  the  daubase  and  ate  not  clipped.  The  aggregation  is  a  kind  of  overiay  on  the  units 
oh  the  battlefield.  Aggregations  ate  hypothesized  by  the  application  of  aggregation  rules,  and 
justified  in  the  ATMS  with  the  units  (and  their  specific  attributes)  grouped  together  as  the 
underlying  assumptions. 

Aggregations  represent  the  situation  hypotheses.  When  a  new  report  entails  an  addition  of  a  unit, 
this  may  result  in  another  aggregation.  This  aggregation  may  contradict  an  earlier  one,  giving  rise 
to  a  second  hypothesis  of  the  perceived  situation.  Another  case  is  when  a  newly  generated  report 
results  in  the  correlation  with  some  unit  structure  used  in  an  aggregation.  The  result  may  be  a 
change  in  the  classified  unit  type,  and  it  may  well  be  that  what  was  thought  to  be  the  unit  type  is 
now  passed  as  a  nogood  assumption  to  the  ATMS.  This  may  in  turn  lead  to  the  removal  of  an 
aggregation  and  thus  the  elimination  of  a  situation  hypothesis. 
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4  Conclusions  and  recommendations 

The  application  described  in  this  chapter  is  in  an  experimental  stage.  It  does  however  demonstrate 
the  usefulness  of  the  combination  of  a  forward  chaining  rule  firing  mechanism,  an  assumption- 
based  truth  maintenance  system  and  a  temporal  database  to  support  a  strategy  for  data  fusion.  The 
facilities  for  predictive  reasoning  and  a  retroactive  adaptation  of  the  database  created  with  this 
combination  allow  to  maintain  multiple  hypotheses  concerning  a  battlefield  environment  with  the 
maintenance  of  assumptions  as  the  key  point.  The  temporal  database  furthermore  suppbits  a  "non¬ 
deletion  policy",  allowing  data  to  be  kept  at  relative  low  cost  because  one  timedist  entry  for  each 
occasion  suffices  to  maintain  its  history. 

An  import  •.■it  rsperi  of  using  an  ATMS  is  computational  efficiency.  Especially  the  mechanism  for 
updating  i.-,  making  sure  that  the  list  of  environments  connected  to  some  faa  is  indeed 
without  con,,  t  iict.ans)  and  the  process  of  handling  nogoods  can  become  very  tricky  from  an 
implen-.:.,  iatioral  s'.anopoint  (Morgue  &  Chehire,  1991).  Again  we  stress  the  fact  that  we  used  an 
implement r  icn  .i.'  the  ATMS  by  (Guoxing,  1989],  we,  refer  to  Appendix  C.  However  this  did 
have  a  i  ^v'lack,  because  the  implementation  needed  code  adaptations  in  order  to  perform 
adequate!:  .Mo.st  notably,  the  subsumption  of  a  pogood  environment  by  existing  environments  in 
the  ATM,;  was  not  calculated  properly,  entailing  that  the  effect  of  passing  a  nogood  did  twt 
propagate  "far  enough"  causing  occasions  to  remain  valid  when  they  were  not  supposed  to.  Apart 
from  rem"  ?;..'  work,  the  adaptation  to  allow  for  the  interaction  with  the  main  program  and  the 
temporal  daiaba.se  was  time-consuming  as  well. 

The  application  and  the  techniques  used  could  be  extended  in  several  ways,  we  also  refer  to 
[Keene  &  Perre,  1990).  As  stated  earlier,  geographical  complexity  was  not  incorporated.  Nor  have 
we  used  any  probabilistic  techniques  to  represent  uncertainty.  This  could  be  done  by  using  for 
instance  the  Dempster-Shafer  theory  of  evidence  as  is  described  in  [Brogi  et  al.,  1984]. 
Incorporation  of  fuzzy  logic  techniques  could  be  even  more  promising  [Sombd,  1990].  The 
forward  chaining  engine  could  be  enhanced  with  certainty  factors  as  well,  which  would  be  a 
relatively  simple  extension,  The  rule-firing  strategy  could  be  extended,  for  instance  by  using  the 
RETE  match  algorithm  to  perform  conflict  resolution  among  applicable  rules  [Merritt,  1989]. 
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Acronyms  and  abbreviations 

ASIC  All  Sources  Infonnation  Center 

ATMS  Assuinption-based  Truth  Maintenance  System 

COMINT  Communications  Intelligence 

DBMS  Database  Management  Svstcm 

DFD  Data  Fusion  Demonstrator 

DFD  Data  Flow  Diagram 

DTG  Date  Time  Group 

EWU  Elecut)nic  Warfare  Unit 

ELINT  '  Electronic  Intelligence 

FEBA  Forward  Edge  of  the  Battle  Area 

PLOT  Front  Line  Own  Troops 

GLB  Greatest  Lower  Bound 

HUMINT  ,  Human  Intelligence 

ISD  Information  Structure  Diagram 

LUB  Least  Upper  Bound 

MEFISTO  Modular  Environment  for  Fusion  and  Interpretation  of  Sensor  data  in  Tracking 
Opposing  forces 

NIAM  Nijssens  Information  Analysis  Method 

ORBAT  Order  of  Battle 

POSTGRES  Post  Ingres 

PROLOG  Programming  in, Logic 

RDBMS  Relational  Database  Management  System 

RMS  Reason  Maintenance  System 

RPV  '  Remotely  Piloted  Vehicle 

TDB  Temporal  Database 

TMM  Time  Map  Manager 

TMS  Truth  Maintenance  System 
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Appendix  A:  The  temporal  database  system 


The  structure  of  the  code  in  this  appendix  is  as  follows: 


1 

Basic  queries 

A.2 

2 

Temporal  distance  calculation 

A.5 

3 

Temporal  queries 

A.7 

3.1 

Relations  between  timepoints 

A.7 

3.2 

Relations  between  timepoints  and  occasions 

A.8 

3.3 

Relations  between  occasions 

A.8 

3.4 

Relations  between  occasions  and  intervals 

A.  10 
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Tequela:  Temporal  query  language 

This  appendix  contains  the  Prolog  source  code  for  the  temporal  database  system. 

The  clauses  governing  the  consultation  and  manipulation  of  the  temporal  database  are  listed. 
These  can  be  divided  into  three  sections.  The  first  contains  predicates  for  the  explicit 
manipulation  of  the  temporal  database,  being  the  direct  addition,  updating  and  clipping  of  timedist 
entries.  The  second  i.s  the  code  for  the  function  performing  the  calculation  of  the  shortest  path 
temporal  distances.  Finally,  a  collection  of  temporal  queries  is  listed  that  allow  to  query  the 
relations  among  timcpoints,  among  occasions,  and  between  occasions  and  timepoints. 


1  Basic  queries 

timedist (ref, ref, 0, 0)  . 
timedist (ref, inf, inf, inf ) . 
timedist (inf, inf , 0, inf) . 


add_timedist(X,Timet:- 

add_limedist (begin (X)  ,end(X) , Time)  . 


add_timedi3t (X, Y, Time) : - 
X  “  begin (A) ,  ' 

Y  ^  end (A) , 

assert (timedist (ref ,X, Time, Time) ) , 
assert  (timedist (X, Y, 0, inf) ) . 


add_t  i.medist  (X,  Y,  Low,  Higti) 

assert (timedist (X, Y, Low, High) ) . 


upd3te_timedi3t (X,Y, Low, High) 

retract (timedist (X, Y,_,_) ) , 
assert  (timedist  (X,Y,  Low, High) )  . 


clip_node (X; ClipTime)  : -  %  in  case  of  a  Itnown  begintime 

timedist (ref , begin (X) , Begin, Begin) , 
retract (timedist (begin (X) , end (X)  ,_Low,_High) ) , 
Timediff  is  ClipTime  -  Begin, 

.  myabs (Timediff, Duration) , 

assert (timedist (begin (X) , end (X) , Duration, Duration) ) , 
nl, 

write ('Node  ’), 
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write(X) , 

write  ('  clipped  at  time  *)» 
write (ClipTime) ,  , 

nl.  /•  Begin  +  Duration  -  ClipTime  */ 


clip_nodeli3t ( [] ,_) 

I  ^ 

clip_nodeli3t ( [HIT] , ClipTime) 
clip_node (H, ClipTime) , 
clip_nodeli3t (T, ClipTime) . 


myabs (A, A) 

A  >  0. 
myabs (A, B) : - 
.  A  <  0, 

B  is  -A 


temporal_b6undarie3 (ReportLi3t,Min,Max) t- 
timelist (ReportList/TimeList) , 
sort (TimeList, SortedTimeList) , 
nttil  (1,  SortedTimeList, Min) , 
last (Max, SortedTimeList) . 


tempo ral_bound3 (X,L1,H1,L2,H2):- 

oalc_temp_distance (ref , begin (X) ,  L1,H1) , 
calc_temp_distance (ref,end(X) ,L2,H2) , 


calc_temp_di3tance(A,B,K,L) 

f indall ( [A, B, K, L) , temporal^distance (A, B, K, L) , List) 
wtite_list (List) , 


time (X) : - 

f indall ( (X, Low, High] , absolut ime (X, Low, High) , List) , 
write_li3t (List) , 


absolutime  (X,  Low,Hig]i)':- 

temporal_distance (ref , begin (X) , Low,_) , 
temporal_distance (ref,end(X) High) . 
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timeliat  ([],(]):- 

,1 

time list ([HIT], [Time ITimeList) > 

asktms (report (H, Time) ,_) , 
timelist (T,TimeList) . 

tell_timedi3t(X,Y):- 

timedist (X, y, Low, High) ,  ' 

nl, 

write_timedi3t (X,y, Low, High) , 
fail. 

tell_timedi3t(_,_) 

nl. 


write_timedist (X,y, Low, High) 
nl, 

write (X) , 

nl, 

write (Y) , 
nl, 

write ('Low  :  '), 
write (Low), 
nl, 

write ('High!  '), 
write (High), 
nl. 
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2  Temporal  distance  calculation 

temporal_di3tance  (B,  E,  Minimum, Maxiir.ura)  :  - 

aggregate ( (max (Min) , min (Max) ], distance (B,e, Min, Max) , [Mini, Maxi) ) , 
(  Mini  >  Maxi 

-> 

(nl, 

write ( 'Temporal  error.'), 
nl 

) 

true 

)  / 

limitnum (Mini , Minimum) , 

limitnum(Maxl, Maximum) .  '  ' 


distance (Tb, Te, Min, Max) 

distance (Tb,Te, (Tb) , 0, 0,MinExp,MaxExp) , 
call (Min  is  MinExp) , 
call (Max  is  MaxExp) . 


distance (Te,Te,_Path,Min,Max,Min,Max) . 
di3tance(tl,Te,Path,Minl,Maxl,Min,Max):- 
timedist (Tl,T2,Minl2,Maxl2) , 
not (member (T2, Path) ) , 
add_di'st  (Minl,Minl2,Min2) , 
add_di3t (Maxl,Maxl2,Max2) , 
distance (T2,Te, [T2 (Path) ,Min2,Max2, Min, Max) . 
distance (Tl, Te, Path, Mini, Maxi, Min, Max) 
tiraedist (T2,Tl,Min21,Max21) , 
not (member (T2, Path) ) , 

3ubtr_dist (Minl,Max21,Min2) , 
subtr_dist (Maxl,Min21,Max2) , 
distance (T2,Te,  1T2 I  Path) ,Min2,Max2,Min, Max)  . 


add_di3t (ref, ref, 0)  . 
add_dist (ref, inf,  1000000)  . 
add_di3t (inf, ref, 1000000) . 
add_di3t (inf, inf ,2000000)  . 
add_di3t(ref,A,A)  . 
add_dist (A, ref, A) . 
add_dist (inf , A, R) 
integer (A) , 

B  is  1000000  +  A. 
add_di3t (A, inf, R) ; - 
integer (A) , 

R  is  A  +  1000000. 
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addi_dist  (A,  B,  R)  :  - 
integer (A) , 
integer (B) , 
R  is  A  +  B. 


subtr_di3t (ref, ref, 0) . 
subtr_di3t (ref , inf , -1000000) . 
3ubtr_di3t (inf, ref, 1000000) . 
3ubtr_di3t (inf, inf, 500000) . 
3ubtt^di3t (ref, A, -A) . 
3ubtr_di3t (A, ref , A) . 
subtr_di3t (inf, A,R) 
integer (A) , 

R  is  1000000  -  A. 
subtt_di3t (A, inf , R) 
integer (A) , 

R  i3  A  -  1000000. 
3ubtr_dist(A,B,R) 
integer  (A),' 
integer (B), 

R  is  A  -  9. 


lijnitnum(Num,  inf )  :-  %  posinf 

Num  >-  999000, 

I  ^ 

limitnum (Num, -inf ) : -  %  neginf 

Num  -<  -999000, 

I 

limitnum (Num, Num) . 
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3  Temporal  queries 

3.1  Relations  between  (itnepoints 

equal (T,T) . 

less (T, inf)  :  - 

not (T  ■  inf) . 
less (ref ,T) : - 

not (T  “  ref) . 
less (T1,T2) 

integer (Tl) , 
integer (T2), 

Tl  <  T2. 


Ie33_equal (_, inf ) . 
l633_equal (ref ,_) . 
Ies3._3qual  (T1,T2) 
integer (Tl) , 
integer  (T2) , 
Tl  -<  T2. 


time^equai ,T1,T2) 

tempo.-al_clistance  (T1,T2, 0, 0)  . 

t ime_les3 (Tl, T2) ; - 

teraporal_di3tance (T1,T2, Low,_High) 
less (0, Low) . 
time_l€3s (T1,T2) 

tempo ral_di3tance (T1,T2, Low, High) , 
less (Low, 0) , 
less (0, High) . 


time_le33_equal,(Tl,T2) 

tempera l_di3tance (Tl , T2 , Low,  High) 
le33_equal(0,Low) . 
time_les3_equal (T1,T2) 

temporal_di3tance (Tl, T2, Low, High) , 
le33_equal (Low, 0) , 
le3s_equal (0,  High) . 


tiroe_in_inte.-val  (T,T1,T2) 

time_less_equal (T1,T) , 
time_less_equal (T,  T2) . 
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3.2  Relations  between  timepoints  and  occasions 

time_during_occasion (Time, Occasion) 
absolutime (Occasion, Low,  High) , 
le3S_equal (Low, Time) , 
time_les3_equal (Time, High) . 


time_before_occa3ion (Time, Occasion) 
absolucime (Occasion, Low,_) , 
less (Time, Low) . 


t  ime_a  f  te  r_occa  s ion ( T ime , Occas ion ) 
absolutime (Occasion, _, High) , 
less (High, Time) . 


time_is_begin_of  occasion (Time, Occasion) 
absolutime (Occasion) , Low,_) , 
equal (Time, Low) . 


time_is_end_of_occa3ion (Time, Occas ion) : - 
absolutime (Occasion) ,_, High) , 
equal (Time, High) . 


3.3  Relations  between  occasions 

earlier (Occasionl, Occas ion2, Occasionl, Beginl, Begin2 ) 

'  3tart3_earlier (Occasionl, Occasion2, Beginl, Begin2) . 
earlier (Occasionl , Occas icn2, Occasion2, Beginl, Begin2 ) : - 

starts_earlier (Occa3ion2, Occasionl, Begin2, Beginl) . 


later (Occas ion 1, Occas ion2, Time) 

3tart3_earlier (Occasionl, Occasion2, _,Time) . 
later (Occasionl, Occa3ion2, Time) : 

start3_earlier (Occasion2, Occasionl, _, Time) . 


later (Occasionl,Occa3ion2,Occa3ion2, Beginl, Begin2) 

start 3_earlier (Occasionl,Occasion2,  Beginl,Begin2) . 
later (Occas ion I,0cca3ion2, Occasionl, Begin l,Begin2) ; - 

3tart3_earlier(0ccasion2, Occasionl, Begin2, Beginl) . 


discriminate (0cca3ionl,0cca3ion2,0cca3ionl,bcca3ion2, Beginl, Begin2) 
St a rt3_earlier (Occas ionl, Occas ion2, Beginl, Begin2) . 
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discriminate (0cca3ionl,0ccasion2,0cca3ion2, Occasion 1, Beginl,Begin2) 
3tatt3_earlier (0cca3ion2,0cca3ionl, Begin2,Beginl) . 

3tatts_earlier (0cca3ionl,0cca3ion2,  Lowl,  Low2) 
absolutime (Occasionl, Lowl/_) / 
abaolutime (pcca3ion2, Low2,_) , 
not (Occaaionl  -  0ccasion2), 
leas (Lowl, Low2) . 


before (Occasionl, 0ccasion2) 

absoltitime  (0cca3ionl,_,  Highl) , 
absolutime (Occa3ion2,  Low2,  _) , 
not (Occasionl  •  Occa3ion2), 
less (Highl,  Low2)  . 


after (Occasionl, Occ_3ion2) 

absolutime (Occasionl, Lowl,_) , 
absolutime (0ccasion2,_, High2) , 
not (Occasionl  »  0cca3ion2), 
less (High2,Lowl) . 


during(Occasionl,Occasion2) 

absolutime (Occasionl, Lowl, Highl) , 
absolutime (0ccasion2, Low2, High2) , 
not (Occasionl  »  0cca3ion2), 
le33_equal (Low2, Lowl) , 
le33_equal (Highl, High2) . 


begin3_during (Occas ionl , Occa3ion2) : - 
abaolutime (Occaaionl, Lowl,_) , 
abaolutime (0cca3ion2, Low2, High2) , 
not (Occaaionl  -  0cca3ion2), 
lesa^equal (Low2, Lowl) , 
less (Lowl , High?) . 


end3_during (Occasionl,Occa3ion2) : - 

absolutime(Occasionl,_,Highl) , 
absolutime (Occasion2, Low2, High2) , 
not  (Occasionl  ”  Occa3ior.2) , 
less (Low2, Highl) , 
le33_equal (Highl, High2) . 

overlaps (Occasionl, Occasion?) 

begin3_during (OccasionljOccasion?) 

end3_during (Occas ionl.  Occasion?) . 
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coincides (Occasionl, Occasions) 

absolutime (Occasionl, Lowl,High) , 
absoiutime (Occasions, Low, High) , 
not (Ocoasionl  -  Occasions). 


dis joint_occasions (Ocoasionl, Occasions) : - 
not (overlaps (Occasionl, Occasions) )  . 


3.4  Relations  between  occasions  and  intervals 

comes_befote  (Occasion,  BegiriTime,_) 
absolutime (Occasion, _,High) , 
less_equal (High,BeginTime) . 


come3_after (0cca3ion,_, EndTime) : - 
absolutime (Occasion, Low,_) , 
less_equal (EndTime,  Low) . 


true_throughout (Occasion, BeginTime, EndTime) 
absolutime (Occasion, Low, High) , 
less_equal (Low, BeginTime) , 
less_equal (EndTime, High) . 


Iie3_in (Occasion, BeginTime, EndTime) : - 
absolutime (Occasion, Low, High) , 
less_equal (BeginTime, Low) , 
le3S_equal (High, EndTime) . 


past_overlap3 (Occasion, BeginTime, EndTime) : - 
absolutime (Occasion, Low, High) , 
not (Low  -  BeginTime,  High  =  EndTime), 
le33_equal (Low, BeginTime) , 
les3_equal (High, EndTime) . 


future_overlap3 (Occasion, BeginTime,  EndTime) : - 
absolutime (Occasion, Low, High) , 
not  ( (Low  BeginTime,  High  =  EndTime)), 
le3S_equal (BeginTime, Low) , 
les3_equal (EndTime, High) . 
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Appendix  3;  Inference  and  interaction  TDB-ATMS 


The  scnicture  of  the  code  in  this  appendix  is  as  follows; 


1 

Inference  engine 

B.2 

2 

Match  and  prov^ess  clauses  ' 

B.4 

2.1 

Match  and  meet 

B.4 

2.2 

Process  and  take 

B.5 

3 

Interaction  with  TDB  and  ATMS 

B.9 
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TDB-ATMS:  Inference  and  interaction 

This  appendix  contains  the  Prolog  source  code  for  the  rule  firing  mechanism  and  the  predicates 
that  handle  the  interaction  between  the  ATMS  and  the  temporal  database. 

The  interaction  with  the  ATMS  and  the  temporal  database  is  triggered  by  the  application  of  the 
mies.  Simultaneous  calls  to  the  ATMS  and  the  temporal  database  will  be  contained  in  the  rales  as 
actions.  The  forward  chaining  rale  application  is  a  "match  and  process"  algorithm  that 
sequentially  steps  through  the  rales. 

The  code  in  this  appendix  is  divided  into  three  sections.  The  rale  firing  mechanism  is  listed  first. 
Secondly,  the  match  and  process  clauses  are  listed,  showing  how  -  among  others  -  the  "assume", 
"derive",  and  "derive_and_xs.sume"  calls  to  the  ATMS  and  the  temporal  database  have  been 
implemented.  This  is  subdivided  into  a  "match-and-mcet"  and  a  "process-and-take”  section, 
re.spectively  dealing  with  the  conditions  and  the  actions  in  the  rules.  The  "takef  Action)"  clauses  of 
the  rale  application  u.se  the  predicates  that  deal  with  the  interaction  between  the  problem  solver 
and  the  ATMS,  the  temporal  database,  as  well  as  the  interaction  amongst  the  latter  two.  These 
predicates  that  are  used  in  the  match  and  process  clauses  arc  contained  in  the  third  section. 


1  Inference  engine 

fire (Type) ;  - 

fire_all  i Type, 


fire (Type, Nr) : - 

fire_ali  (Type, Nr, _,_,_) 


fire_all  (Type, Nr, Description,  I.HS,RHS) 

rule(Type, Nr, Description) ::LHS=->RHS, 
f ire_rule (Type, Nr, Description,  LHS,  RHS) , 
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f ire_rule (Type, Nr, Description, LHS, RHS) : - 
match (LHS), 

process  (RHS, LHS, Type) , 
writerule (Type, Nr, Description) , 
fail . 
fire_rule 
nl, ' 

write ('Fire  rule?  '), 
read  (Answer) , 
carry_out (Answer) , 


carry _out  (y)  : - 
( 

•  ! 

fail. 

carry_out  (n)  ;  - 

carry_out (_) : - 
nl, 

write('Not  a  valid  command,  enter  (y/n) :  '), 
read (Answer) , 
carry_out (Answer) . 


writerule (Type, Nr, Description) : - 
nl, 

wrice('Rule  fired:  ’), 

wt ite (Type) , 

writeC,  '), 

write (Nr) , 

writeC,  ’), 

write (Description) , 

nl , nl , 


write_list ((]):- 

I 

write_li St ( [H | T] ) ; - 
write(H) , 
nl , 

write_ii3t  (T)  . 
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2  Match  and  process  clauses 

2. !  Match  and  meet 

match ( [] )  ;- 

I 

match ( [Condition  I  Rest ) ) : - 

t 

•  ! 

meet (Condition) , 
match (Rest! . 

meet (tma (neg (Prem) ) ) : *  %  meet  tms  condition 

!. 

tm3_node  (_,  neg  ( P  rem) ,  in,  . 

meet  (tms  (not  (Prem) )):  -  ~ 

» 

•  t 

not (node_exi3t3 (Prem, in))  . 
meet (tma (out (Prem) ) ) 

I 

•  f 

tms_node (_, p  rem, out , _, _, _) . 
meet  (tms  (Prem)  ):  -  ~ 

tms_node (_, Prem, in, . 

meet (neg(Prem) ) :-  %  meet  prolog  condition 

neg  (Prem) . 
meet (not (Prem) ) :- 
1 

,  •  f 

not (Prem)  . 
meet (Prem) : - 

•  f 

Prem, 
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2.2  Process  and  take 

prpeeas 
»  ' 

process ( (Action  1  Rest ) pLHSpType) 
take (Action*  LHS*Type) * 

t 

• » 

process (Rest, LHS,Type) , 


take (asktms (X, Status), 
asktm.s  (X,  Status)  . 
take ( replace_node (X, Y) ,_,_) 
tm.<!_replace  (X,  Y)  . 
take  (add_pcemise  (X,  Time) ,_,_)  :  - 
a'ld_premi3e(X,Time)  . 

take ; assume (X, Time) ,_,_); - 

(check_node_exi3t3 (X,_) 

build_tms  node(X) 

assurae_node (X) , 
nl, 

write ( 'Adding  assumption:  '), 
write (X) , 

add_timedi3t (X, Time) , 
nl, 

write (' Starting  at  time  :  '), 
write (Time) , 
nl . 

take (derive (neg  » ,_, Time) , LHS, Type) : - 
X  =”  neg  ( Y)  , 

t  a ke (derive (Y,_) , LHS, Type) . 
take (derive (neg (X) , NogoodNodeLi3t,Time) , LHS,  Type) : - 
(  check_node_exist5  (neg  (X) ,_)' 

build_tms_node (neg (X) ) 

) , 

(  (check_as3umpt ion (X) , 

pa3s_nogood (X, NogoodNodeList ) 

) 

NogoodNodeList  =  [) 

) , 

make_antecedent_li3t (LHS, Ante_List) , 
new_ju3tif ication (Type,neg(X) , Ante_List) , 
nl, 

write ( 'Adding  justification  for:  '), 
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write (neg (X) ) , 
add_timedist (X, Time) , 
nl,  ■ 

write ( 'Starting  at  time:  '), 
write (Time) ,nl. 

ta)te  (derive  (X,NogoodNodeLi3t,Time) ,  LHS,  Type) 

(  checlc_node_exi3t3  (X,_) 

build_tm3_node (X) 

). 

'  (  (checlc_a33umption(neg(X) ) , 

pa33_nogood (neg (X) ,NogoodNodeList) 

) 

NogoodNodeList  -  [] 

), 

make_antecedent_li3t  (LHS,  Ante_I.ist) , 
new__ju3tif  ication  (Type,X,  Ante_Li3t) , 
nl, 

write ( 'Adding  justification  for:  '), 
write (X), 

add_timedist (X,Time) , 
nl,  ■  ‘ 

write( 'starting  at  time:  '), 
write (Time), 
nl . 

talce,(detive_ahd_a3Sume(neg(X),_, Time), LHS, Type)  :- 
X  -  neg(Y) , 

take (derive_and_as3ume (Y,_,Time) , LHS, Type) . 
take (deri ve_and_a33ume (neg (X) , NogoodNodeList, Time) , LHS, Type) : • 
(  check_node_exi3t3 (neg(X) ,^) 

build_tms_node{neg(X) ) 

)  /  ,  ' 

(  (check_assumption (X) , 

pa3S_nogood (X, NogoodNodeList ) 

) 

NogoodNodeList  “  [} 

), 

make_antecedent_list (LHS, Ance_List) , 
new_ju3tification (Type, neg (X) ,Ante_Li3t) , 
a33ume_node  (neg  (  ?) ) , 

,  nl, 

write ( 'Adding  justification  and  setting  assumption:  '),  . 
write (neg (X) I , 
add_timedist (X, Time) , 
nl, 

write ( 'Starting  at  time:  ’), 

write (Time), 

nl. 
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take (derive_and_as3ume (X.NogoodWodeList, Time) , LHS, Type) : - 
(  check_node_exl3ts (X,_) 

build_tm3_node (X) 

)  r 

(  (check_a33umption<neg(X) ) , 

pa33_nogood(neg(X) ,NogoodNodeLi3t) 

) 

NogoodNodeLiat  ”  [] 

)  f 

maka_antecedent_list (LHS,Ante_Li3t) , 
new_ju3tif ication (Type,X, Ante_Li3t) , 
a33ume_node (X) , 
nl, 

write ( 'Adding  juatification  and  setting  assumption;  '), 
write(X), 

add_t imedist (X, Time) , 
nl<  '  . 

write (' Starting  at  time:  '), 
write.(Time) , 
nl . 

take(set_node(X,out),_,_):- 

check_node_exi3t3 (X, out) . 
take (3et_node (X, out ),_,_); - 

check_node_exi3t3 (X, in) , 

3et_node (X, cut ) . 
take (3et_node (X, out) <_>_) 
build_tm3_node <X) . 
take(pa3S_nogood(X,List),_,_):- 
pa33_nogood()C,Li3t)  . 
take (set_nogood (X, Time) - 
3et_nogood (X, Time) , 

take  (t imedist  (X,  Y,  Low,  Higti) ,_,_) 
t imedist (X, Y, Low, High) , 
take(temporal_di3tance(X,Y,Min,Max),_,_):- 
temporal_di3tance (X, Y,Min,Max) . 
take  {add_t  imedist  (X,y,  Low,  High.) ,_,_) 
add_timedi3t (X,Y, Low, High) . 
take  (assert  (X)  ,_,_): - 
assert (X) . 

take  (retract  (X) »_/_),:  * 
retract (X) . 
take (call (X) ,_,_): - 
call (X) . 
take(  (X;  Y)  ,_,_) 

take(X,_,_) 

take . 
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take((X  - 

X  -  Y.  ~ 
take  ( (X  $  Y) 

X  ia  Y. 
take  (write (X) 

write (X) .  ~ 
take(write_li3t (X) 

write_li3t<X)7 

take(nl,_,_) 

nlT 

take  (reacKX) 

tead(X) . 

take  (prompt  (X,  Y) 
nl, 

write (X), 
read(Y) . 

take(;<,_,_)  %  if  aii  else  fails 

call(X) 

fail'. 


make_5ntecedent_list([), tj) 
make_antecedent_li3t((HIT],  (XIListl) 

H  -  tm3(X), 

make_antecedent_list (T,Li3t) . 
make, 3ntecedent_li3t (Th IT) , List) : - 

\+  H  ^  tms (_) , 

make_antecedent_li3t (T, List) , 
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3  Interaction  with  TDB  and  ATMS 

asktms (X, Status) 

tm3_node(_,x, Status, . 


fetchtms (X) 

asjctms  (X,  in)  . 
fetchtms (  ) ; - 


chec)5_node_exi3t3  (X,  Status) 

tm3_node (_, X, Status, . 


teli_node (X, Status) 

tms_node (_, X, Status, ), 
ni,  -  _  _ 

write (X) , 
fail . 

teli_node (_,_) : - 
n  1 , 


chec)t_as3unpt  ion  (X):- 

t.Tis_node  X,  in, ( 'Assumption* ) )  . 

tell_aS3umption(A) 

assumption A,  ), 
nl,  .  ~ 

write (A) , 
fail. 

tell_assumption  (  );- 
nl. 


tm3_replace (X,  Y)  : - 

retract  (tm8_node  (N,X,S,  L,  j',C,R,  P) ) , 
assert  (tms_node  (N,  Y,  S,  L,  J,  C,  R,  P)  )  , 


set_node (X, out ) ; - 

retract (tms_node (_fX, , 
assert  (tm3_node  (_,X,  out,  ,  ,  7  )) 

3et_node <x, in)  :  - 

retract  (tms_node(_,X, , 
assert  (tms_node  (_,X,  in, ) )  , 
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add_premi3e(X/T) 

build_tm3_node (X) , 
3et_premi3«_hode (X) « 
add  clmedlat (X,T) , 


add_a3sumption(X,T) ' 
build_tni3_node  (X) , 
a33ume_node (X) , 
add_timedi3t (X,T) . 


add_ju3tification(X,A,T) 
build_tm3_node (X) , 
new_ju3tification(ju3t,X,A) , 
add  timediat (X,T) . 


pa33_nogood(X,NogoodNodeLi3t) 

set_nogood_node3 ( [X] ,NogoodNodeList) , 
nl, . 

write ( 'Setting  nogood:  '), 

write (X), 

nl,nl, 

writeCNodes  set  to  out  by  ATMS  are:  *), 
nl/ 

write_list (NogoodNodeLiat) / 
nl. 


pa33_nogood_li3t . 

pa3S_nogood_li3t ( [XI  Rest] ,Time,TotalLi3t) 
pa33_nogood{X,NogoodList) , 
append (NogoodList , List , TotalList ) , 
pas3_nogood_li3t (Rest, Time, List) . 


set_nogood(X,T) 

pas3_nogood (X, List) , 
clip_node (X,T) , 
clip_nodeli3t (Li3t,T) . 
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Appendix  C: 

The  Assumption-based  Truth  Maintenance  System 


The  structure  of  the  code  in  this  appendix  isi  as  follows: 


1 

Build  nodes,  assumptions,  environments 

C.3 

2 

Build  justification 

C.5 

3 

Update  node 

C.6 

4 

Update  label 

C.7 

4.1 

Compute  justification  environment 

c.g 

4.1,1 

Make  environment  from  assumption  ■ 

C.8 

4.1.2 

Oenerate  environment  cross  product 

C.9 

4.2 

Remove  subsumed  environments 

C.12 

4.2.1 

Environment  subsumed 

C.16 

4.2.2 

Check  contradictory  environments 

C.17 

5 

Update  nogood 

C.l  9 

5.1 

Process  nogood  tables 

C.20 

5.2 

Process  envirotunent  tables 

C.21 
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ATMS  ,  Assumption-based  Truth  Maintenance  System 

The  implementation  of  the  ATMS  is  based  on  the  implementation  in  Prolog,  listed  in  [Guoxing, 
1989].  We  have  adapted  the  code  to  acquire  an  interface  with  our  application,  to  facilitate 
interaction  with  the  temporal  database  and  to  remove  some  errors  from  the  original  code. 
However,  we  stress  that  the  basic  algorithms  governing  the  ATMS  are  unaltered  and  attributed  to 
[Guoxing,  1989],  The  size  of  the  ATMS  implementation  is  over  26  KB,  we  will  not  list  the 
complete  code  here.  Below,  we  list  selections  from  the  ATMS  source  code,  indicating  the 
adaptations  that  we  have  made  that  do  not  only  concern  the  interface. 

The  ATMS  implementation  has  four  main  functions  that  govern  the  construction  and  maintenance 
of  the  four  main  data  structures  of  the  ATMS,  discussed  in  paragraph  3.3.2.  The  functions  .are  the 
following: 

build_node. 
build_assumption . 
build_environment . 
build_ju3tif ication. 

The  three  functions  corresponding  to  the  building  of  nodes,  assumptions  and  justifications  are 
initiated  from  outside  the  ATMS,  as  ciarided  in  this  report.  The  ”build_environment"  function  is 
initiate  by  the  ATMS  itself,  by  the  "buildjustification"  function,  which  form:;  the  heart  of  the 
ATMS.  It  is  this  latter  function  that  initiates  the  truth  maintenance.  When  a  new  justification  is 
passed  to  the  ^TMS,  three  main  functions  are  triggered  to  recalculate  the  consistency  of  the 
database.  These  functions  are  the  updating  of  nodes,  the  updating  of  labels  and  the  updating  of 
nogoods. 

The  updating  of  nogoods  uses  envirorunent  tables  and  nogood  tables  as  main  data  strucnires.  The 
environment  tables  contain  the  environments  in  the  ATMS,  they  are  ordered  by  the  number  of 
assumptions  the  environments  consists  of.  Thus,  there  is  an  environment  table  containing  the 
environments  with  one  assumption,  with  two  assumptions,  etcetera.  Nogood  tables  are  used  to 
keep  track  of  the  inconsistent  environments  in  the  ATMS,  and  thus  the  inconsistent  assumptions. 
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The  main  adaptation  .ecessary  in  the  ATMS  itself  to  allow  a  combination  of  tnith  maintenance 
and  temporal  reasoning  techniques  is  to  incorporate  the  returning  of  a  list  of  die  nodes  that  were 
set  to  out  as  a  result  of  a  recomputation  of  the  labels,  see  paragraph  3.4.2  and  3.4.3.  The 
'NogoodNodeList''  records  the  nodes  set  to  out  in  the  course  of  the  label  update  mechanism.  It 
was  added  to  the  code  in  several  places,  because  it  "snakes"  through  the  program.  It  is  explicidy 
constmeted  by  the  ATMS  in  die  ’'do_delete_env"  tunction.  see  page  C.  1 8. 

There  were  several  errors  in  the  code  that  needed  repair.  The  main  error  was  that  on  passing 
riogoods  to  the  ATMS  'he  calculation  of  the  subsumption  did  not  travel  "far  enough"  through  the 
ATMS.  Beside  this,  all  environments  were  set  to  "contradictory"  due  to  this  incorrect  calculation 
of  the  subsumption.  The  result  was  that  nodes  remained  valid  incorrectly  because  their  labels  were 
not  correcUy  adjusted.  The  errors  and  adaptations  made  arc  stated  in  the  code  below. 


1  Build  nodes,  assumptions,  environments 

build_tm3_node 

build_tm3_node (Datum) 

(tm3_node (_, Datum, 

-> 

(wr:te('Node  already  existed'), 
nl 

) 

(node_count (C) , 

assertz  (tms_node  (C,  Datum,  out  ,0, (,,[),[],[])) 

) 

), 

3ystem_init 1 . 

%%  build_as3umption 
build_a33umption (Datum) 

tms_node  (Index,  Datum,  Status,  Label,' Ju.tJ  ,  Consq,  Rules,?  list), 
adc'._element  ( '  Assumpt  ion ' ,  Plist ,  PI ) , 

retract  ( tms_node  (Index, Datum,  Status,  L.ii  -  . ,  .lust i, Consq,  Rules,  Plist) 

)  / 

assumption_count (C) , 

assertz (assumption (C, Datum, (] ) ) , 

assertz (tms_node (Index, Datum, Status, Label, Just i, Consq»  Rules, Pi) ) . 
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1%  build_environin«nt 

build_environment (Aaaum) 

environment_count (C) , 
length (Aasum, Len) , 

aaaertz (environment (C, Len, Aaaum, () / f] ) ) » 
f ill_a33um_env (Aaaum, C) , 
inaett_env_in_table(Len,C) . 


fill_a33um_env ([],_): -  , 

f ill_a3aum_env( (HIT], Env) 

retract (aaaumption (H, Aaaum, Oenv) ) , 
otd_add_element (Oenv, Env, Nenv) , 
aaaertz (aaaumption (H, Aaaum, Nenv) ) , 
f ill_a33um_env (T,  Env)  . 

inaert_env_in_table (Len, Env_index) 
retract (env  table (Len, Eaet) ) , 
ord_add_element (Eaet,Env_index,El) , 
aaaertz (env_table (Len, El) )  . 
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2  Build  justificarion 

build_ju3tif ioation (Type.Conseq, fntes^NogoodNodeLiat ) : - 
%  NogoodNodeList  added,  snakes  through  test  of  the  ATMS 
justification_count (C) , 
push_j_tms_node_just (Conseq.C' , 
push_j_tms_node_cons (Antes, C) , 
assorts ( justif ication (C,Type, ^onseq, Antes) ) , 
update_iomething (Conseq, Cj NogoodNodeList ) . 


pu3h_j_tm3_node_ju3t (Conseq, Ju3t_i  lex) 

retract (tm3_node (Conseq, D, S,  L, J,Con3,  R, Pli3t ) ) , 

ord_add_element ( J, Just_index, N just ) , 

asserts (tms_node (Conseq, D, S, L, N just , Cons, R, PI ist ) )  . 


push_ j_tm3_node_cons ( t  J , _) ; - 

push_j_tms_node_con3 ((HIT), Ju3t_index) : - 
proces3_one_by_one (H, Ju3t_index) , 
pu3h_j_tms_node_con3 (T, Ju3t_index) . 


,pcoce33_one_by_one (Ante, Just_index) 

retract  (t<ns_node  (Ante,  0,  S,  L,  J,Cons,  R,  Plist )  ) , 
(Plist"" t 'Assumption ' )  . 

-> 

assert z  (tm3_node (Ante, D, S, L, J,Cons, R,  Plist ) ) 

(ord  _add_eletTient  (Cons,  Just_index,  Neons', , 
asserts (tms_node (Ante,  D, S, L,  J,  Mcons, R,  Plist ) ) 

) 

)  . 


update_3omething (Conseq, Ju3t_index, NogoodNodeList ) : - 
tm3_ndde (Conseq, Datum, , 
(Datum==contra_node 

-> 

update_nogood  ( Just_iiidex,  NogoodNodeList) 

(retract (node_queue (X) ) , 
ord_add_elenient  (X, Conseq,  XI )  , 
asserts (node_queue (XI )) , 
update_node (XI ) 

)  ■  '  . 
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3  '  Update  node 

update_node { [ ] ) : - 

t 

update_node ( [H l_TJ )  :  - 
update_label (H) , 
tnodi_node_queue  (H) , 
do_loop_te3t (H) , 
node_queue (Qt ) , 
(Ot— t! 


update_node (Qtl 
)  . 

tr.odi_node_queue  (Nd) - 

tetract  (n'Ode_queue  (Nq)  ) , 
del_eleiT!ent  (Nd,Nq,Nql) , 
assertz  (nede_queue  (tJql)  )  . 

do_loop_test (H) 

new_env (New_env) , 
(New_env««( ] 

-> 


(tr.3_node  (H,_Datuw,  Node_conseq,_,_) , 

dc!_li3t_con3eq  (Node_ccnseq) 

)  . 

do_list_con3eq( [ 1 ) : - 

r  ■  , 

clo_li3t_con3eq([HlTJ):- 

justif ication {H,_Typee  Justi^con3eq,_) , 
clo_just  i_conseq  (H,  Just  i_conseq) , 
do_li’3t_conseq<T)  , 

do_ just i_conseq (H, Conseq) 

Conseq==cont  ra_node 
-> 

upda  t  e_r.ogood  ( H ,  _) 

add_node_queuG (Conseq) . 

add_nod€_queue(Node):- 

retract {node_queue (Queue) ) , 
ord_add_ei€ment (Node, Queue, Ql) , 
asserts (node_queue (Qi) ) . 
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4  Update  label 

update_label (Node) 

tm3_node (Node, _Datum,_, Label, ) , 
(Label— (1 
-> 

■  (retract (env_product (_)) , 
aaaertz (env_product ( (1 ) ( 

) 

do_updat  ■■  _',-<bol  <  Jus ti, Node) 

)  .  '  ' 

do_update_label ((),_' : - 
» 

do_update_label ( (h IT) .  N.  de) 

compute_ just i f ic it ion_env (H) , 
env_product (Penv) . 

■  process_penv (Penv . Node) , 
do_update_label (T,Node) . 

h%  compute  justification  environment 

corapute_ju3ti£ication_env(H) 

justification (H,_Xype,_, Antes) , 
proces3_ances (Antes) , 
comm_proces3_f or_pcoce3s_antes . 

process_antes  (  [  ] )  :  - 

I 

process_antes ( [HIT) ) 

i  tms_node  (H,Datum,_,  Label,_,_,_,  Plist ) , 

(Pli st== ( ' Assumpt ion  ' } 

-> 

(assumption  (Ind, Datum, __) , 
push_input_as3uraption (Ind) 

,  )  '  . 

push_input_en vs (Label) 

) , 

process_antes(T)  . 

pus;i_input_assumption(H);- 

ret ract ( input_a3 sumption (lassum) ) , 
ord_add_element (Iassum,H, li) , 
assertz  ( input_a3sumpt  ion  (ID  )  . 

push_input_envs(I,abel) 

retract (input_envs (Env) ' , 

,  ord_union (Label, Env,  El) , 
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li3t_to_ord_3et (El,  E2) , 
a33ertz  (iriput_env3  (E2) )  . 

comm_proce33_for_proca3s_ante3:- 
■ input_as3umption(A33um3) , 
nialce_env_f  rom_a3Sumption  (Aasums) , 
ba3e_env(Ba3e_env) , 
input_env3  tEnv_choice3) , 

( (A33Um3““{] 

,  Ba3e_env\— ( ) 

) 

generate_env_cros3  _product (Base_env,Env_choice3) 
generate_env_cro3s_product ( [] ,Env_choices) 


4.1  Compute  justification  environment 

4.1.1  Make  environment  from  assumption 

nvake_env_f  rom_assumption  ([]):- 
( 

make_env_f rora_a3Sumpt ion { (H IT] ) 
base_env<Base  env) , 
con3_env (H, Base_env) , 
ba3e_env (Nenv) , 

(Nenv”« ( ] 

-> 

(retract  (base_env(_) > , 
assertz (base_env ( [  1 ) ) 

)■ 

malr__env_f  rom_a3Sumption  (T) 

)  . 


con3_env (Assum, Env) : -  ' 

ord_add_element (Env, Assam,  Nenv) , 
(environment (  E_ind,_, Nenv,_,_) 
-> 

con3_env_r3tu  "n2  (tie  •- ) 

cons_env_roturnl  (Ne:  v) 

.  )  . 
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cons_env_returnl (Env) 

build_environment (Env) , 
environment (E_ind,_, Env,_,_) , 
(check_contradictory (E_ind) 

-> 

(retract (ba3e_anv(Benv) ) , 
assert z (ba3e_env ((]) ) 

) 

(retract (ba3e_env(Benv) ) , 
assertz (ba3e_env{Env) ) 

)  . 

cons_env_teturn2(Env) 

environment (_E_ind,_,Env,_,Contr) , 
(ContrN-*  ( ) 

-> 

(retract (base_env(Benv) ) , 
assertz  (ba3e__env ((]) ) 

) 

(retract (ba3e_env{Benv) i , 
assertz (base_env(Env) ) 

) 

)  . 


.  4.1.2  Generate  environmcn(  cross  product 

generate_env_cros-,jiroduct  (Ba3e_env,  (])  :- 
env  product (Env_p) , 
environment (Ind»_, Base_env,_,_) , 
(Env^'s'^O 
'> 

pusn_in_env_product (Base_env) 
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( (new_env_nubsumed<Ind,Env_J>) 

check_contradictory (Ird) 

) 

-> 

I  pu3h_in_env_product  <Ba3e_env) 

<do_check_3ubsumed (Ind, Env_p) , 
pu3h_in_env_product (Ba3e_env) 

) 

) 

)  . 

generate_env_cro33_ptoduct (Ba3e_env, [H|T]):- 
retract (base_env (_) ) , 
aaaertz  (base__env  (Ba3e_env) ) , 
append_env3 (H,Ba3e_env) , 
ba3e_env (Nenv) , 

(Nenv--[] 

.  -> 


generate_env_cros3_product (Nenv, T) 

)  . 

pu3h_in_env_pE0duct (Base_env) 

retract (env_product (Env_product) ) , 
environment (Ind,_, Ba3e_env,_,_) , 
(Env_product=*’0 
-> 

ord_add_element ( (1 , Ind,Ep) 

ord_add_element (Env_product, Ind,Ep) 

), 
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li3t_to_ord_3et (Ep,Epl) , 
a33ertz (env_product (Epl) )  . 

append_env3 (0ne_of_input_anw3,  (I):- 
retract (ba3e_env(_) ) , 

environment (One_of_input_env3,_, A33um3,_,_) , 
a33ertz(ba3e_env(A33um3)) . 
append_env3 (One_of_input_env3,Ba3e_env) 

environment  <0ne_of_input_anv3,Nl, AS3uml,_,_) , 
environment  (_Ind, N2,  Ba3e_env, 

(N1  >  N2 

-> 

( ret ract (ba3e_env (_) ) , 
assert  2 (ba3e_env (Assuml ) ) , 
make_env_from_as sumption (Base_env) 

) 

make_env_f rom_a3 sumption (Assuml) 


do_cheok_sub3umed(_/ [1 ) 

» 

do  check_3ub3umed(Base_env, [HIT]) 
env_subsumed(H, Base_env) 

-> 

( ret ract (env_product (Env_p) ) , 
ord_del_element (Env_p,H,E3) , 
assertz (env_product (E3) ) , 
do_cheok_subsumed (Base_env,T) 

) 

do_check_subsumed (Ba3e_env,T) . 
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4.2  Remove  subsumed  environments 

procea3__p«nv(Penv,Node) 
new_env (New_env) , 

,  ca3e_one(Penv,New_env)', 
ca3e_euo(Node) . 

ca3e_one ((],_) 

,  I  ^ 

ca3e_one ( [HIT] ,New_env) 

(New_env— [] 

-> 

ordec_pu3h_penv (H) 

3ub_ca3e_one (H, New_env) 

)  ! 

new_env  (,Nnenv) , 
ca3e_one('r.Nnenv)  . 

3ub'_case_one  (Penv,  Nsw_env)  ;  - 

new_env_3ub3uined  (Penv,  New_env) 
->  ~ 


(check_contradictory (Penv) 
-> 


do_inodify_new  env  (Penv,  New_env) 
)  . 

new_env_3ubsumed (_Penv, (] ) :- 

I 

•  9 

fail. 


I 

I 
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new_env__subs'jfned (Penv,  fH!T)) 
env_3ubsunied  (Penv,  H) 


new_^env_sub3umed (Penv,T)  . 

do^modi f y_new_env ( 1 ) : - 
» 

do_modify_new_env (Penv, [HIT]):- 
(env^subsumed (H, Penv) 

“> 

(retract  (new_^env  (Nev'_env)  )  , 
del^element  (H,  N'ew^env,  N1  ‘ , 
assert  2  (new_^er^v(Nl)  ) , 
order^push  jDenv (Penv) 

) 

order^push_penv (Penv) 

) , 

do^modi fy^new^env (Penv,  T) . 

order_push  penv (Penv) 

retract  (new__^env{Env)  ) , 
ord_add_eienent  (Env,  Penv,  New_er,v) , 
assert  z  (new_env  (New_^€nv)  )  , 

case^twc  (Node* 

tms_node  (Node,__,_,  Label, , 
new_env (New  env) , 

(seteq (Label, New_env) 

(retract (new^env (_) ) , 
assert  z  (r,ew_env  ([  J ) ) 
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) 

(ciel_env_nodes  (Label, Node, New_env) , 
aad_env_nodes (New_env,Node, Label) , 
modify_node_label (New_env, Node) , 
modify_node_otKer_f ielda (New_env, Node) 

) 

)  .  ' 

del_env_node3(0,_,_) 

I 

del_env_node3 ( t 1 ,_,_) :~ 

I  !  . 

del_env_node3 ( fH I TJ , Node,  New_env) : - 
(subset (H,N6w_env) 


(retract (environment (K, N, A, Enode, Cont r) ) , 
del_element (Node, Enode, El) , 
assert z (environment (H,N, A, El,Contr) ) 

) 

r, 

del_env_node3 (T,Node,New_env) . 
add_env_nodes ((]>_»_):" 

I  ^  . 

add_env_nodes ((HIT) ,Node, Label) 

(subset (H, Label) 

-> 


(retract (environment (H, N, A, Enode, Contr) ) , 
ord_add_eleraent (Enode, Node, El) , 
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aasertz (environment (H,N, A, El,Contr) ) 

) 


)  t 

addl_onv_node3  (T, Node,  Label)  . 

modify_node_label (New_env,Node) 

retract (tm3_node(Node,D,S,_L, J,C,R,P) ) , 
aasertz (tma_node (Node,D,S,New_env, J,C, R, P) ) . 

%code  added  for  the  case  New_env-{)  and  Ll”{) 
■nodify_node_other_f  ields  {New_env,  Node)  :  - 

retract (tm3_node (Node, Dl, _S1, LI, R1 , PI) ) , 
(New_env»“() 

-> 

(LI— (J 

-> 

assert z (tms_node (Node, 01, in, LI, J1,C1, Rl, PI) ) 
assert z  (tms_nbde  (Node,  Dl,  out,  L1,,J1,C1,  Rl,  PI) ) 

) 

assertz  (tms_node  (Node,Dl,  in,Ll,Jl,Cl,Rl,Pl)) 

)  . 


TNO  report 


Page 

C.16 


4.2.1  Environment  subsumed 

en\._subsumed  ([),[]); - 

I 

env_3ubsumed(_,  [])  :- 

I  ^ 

env_sub3umed ( ( ] /  ) : - 
fail. 

env_3ub3umed(El,E2) 

El— E2,  ' 

I 

env_3ub3umed(El,E2) 

environment (El,Nl,As3umsl,_,_) , 
environment (E2,N2, A3sum32,_,_) , 

(N1  <  N2 
-> 
fail 

checIt_assumption_f  rom_env(As3umsl,  A33ums2) 
)  .  ” 

checlt_a33umption_f  rom_env  ( ( ) ,  (]) 

f 

chec)c_as3umption_ftom_env<_,  ())  :- 

I 

check__assumption_from_env(  (1 

•  I 

fail . 

check_a33um.pt  ion_from_env  ( (HI  ITl] ,  [H2IT2])  , 

(H1==H2 
-> 

check_a3  3umpt ion_f  rom_env (T1 , T2) 
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(HI  <  H2 
-> 

check_a33ump*‘ion_frora_env(Tl,  tH2|T2]) 
fail 

\ 

■  '  i 

i 

4.2.2  Check  contradictory  enviroiunents 

check_contradictory(Env_ind):- 

environment  (Env_ind,  N,_A33uins, Cont  r) , 

(Contr\— (1 


lookup_nogood_table  (it,  Env_ind) 
)  . 


lookup_nogocd_table (N, Env_ind> : - 
countk (I) , 

nogood_table (I, Cenv) , 
i  =<  n” 

-> 

( 3ub3uraed_nogood (Cenv,  Eriv_ind,  I ) 
-> 

end_lookup_nogood_table 
lookup_nogood_table (N, Env_ind) 

(end_lookup_nogood_table, 

.fail 
)  . 
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endl_lookup_nogood_table :  - 

retract  (countlc_aux(_) ) , 
asaertz (countk_aux(0) ) , 


sub3umed_nogood ( t ]/_»_) J ” 

'  ! 

fail.. 

3uDsumed_nogood ([HlTl,Env_ind,I) 
env_3ub3umed ( Env_ind, H) 

-> 

(retract (environment (Env_ind,Num, A33um3/Node3,_Contr) ) , 
assertz (environment (Env_ind,Num,A33ums, Nodes, H) ) 

)  ■ 

3ub3umed_nogood(T, Env_ind, I) . 
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5  Update  nogood 

update_nogood (Just , NogoodNodeList ) : - 
eompute_justif ication_onv i Juat) , 
env_product (Env_produot) , 

clear_nogood  {Env_jproduct ,  Just ,  NogoodNodeLiat )  . 

%  code  adapted,  before:  when  Env_product  “  0  '*clear_nogoo J"  failed 
Clear_nogood ([]/_/_): ■ 

I 

c lea  r_nogood ( [ H I T ] , Just , NogoodNodeLiat ) : - 

retract (environment (H, N, Assam, Nodes, _Contr) ) , 
aasertz (environment (H,N,Assum, Nodes, Just) ) , 
remove_env_f rom_labeia (H, NogoodNodeLiat) , 
insert_nogood_in_table (N, H) , 
proce33_nogood_t'able  (N,  H) , 
process_env_table (N, H) , 
clear_nogood(T, Just, NogoodNodeLiat) . 

remove_env_f rom_label3 (Env, NogoodNodeLiat ) : - 
environment  (Env,_N,_As3um, Nodes, _Contt.) , 
do_delete_env  (Nodes,  Sr.v, NogoodNodeLiat )  . 

%  code  adapted,  NogoodNodeLiat  is  constructed  here 
do_delete_env ((],_,  ( 1 )  : - 

I  _ 

do_delete_env ( (H I TJ , Env, (NogoodNode I  List ) ) : - 
retract  (tms_node  (H,D,S,L,J,C,R,P)), 
del_element (Env, L, LI) , 

(Ll«:] 

-> 

(asserts  (tms  node  (H, D,.out ,  0,  J,C,  R,  P) ) , 

NogoodNode  =  D 

) 
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(assertz  (tms__node  (H,  D,  S,  LI ,  C,  RV  P) )  t 
NogoodNode  *  [} 

) 

.)•  ■ 

retract (node_queue (Node_q) ) # 
ord_add_eiefnent  <Node_q,  H,  Model ) , 
assert2(node_queue (Model) ) /.  , 

do_delete_env(T,Env,  List) . 

in3ert_^nogood_ln_table  (N^assums,  Env)  :  - 
N_assum3*»0 

t 

(retract (nogood_table (N^assums, Nogood) ) , 
•  ocd_add_element (Nogood, Env, Nnogood) , 
aasertz  (r>ogood_table  (N^aasums, Nnogood) ) 
)  .  • 


I 

i 


5.1  Process  nogood  tables 

process^nogood^^table  (0,__) 

j  ^ 

proce33_nogood_table (129#_)  *- 

I 

process_nogood_table (N,Cenv) 
nogcod_table (N, Nogood) , 

'  do_te3t_nogood_sub3umed (Nogood, Cenv, N) , 

Y  is  N+1, 

process_nogood_tabie (Y,Cenv) . 


{ 
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■do_te3t_nogood_3ubsumed  (  [  i i 

do_te3t_nogood_3ub3umed( IH I T) ,Cenv, N) ; - 
(H--Cenv,  , 

T— 1 ! 

) 


(env_3ub3umed (H,  Cenv) 

-> 

(dele_h_f  roir_riogood_table  (N,  H) , 
do_te3t_nogogd  subsumed (T, Cenv, N) 
)  ~ 

do_te3t_nogood_subsum/^d  ('r,Cenv,N) 

)  . 

dele_h_from_nogood_table (N, H) 

retract (nogood_table (N, Nogood) ) , 
del_element (H, Nogood, Nnogood) , 
assert (nogood_cable (N, Knogood) ) . 


5.2  Process  environment  tables 

proce33_env_tabae(0,_) 

t  ^  ** 

proces3_env_table(129,_) 

I  _ 

proce33_env_table (N,Cenv) 

env_table (N, E_table) , 
do_te3t_env_3ubsumed (E  table, N, Cenv) , 
Y  is  N+1, 

proce33_env_table{Y,Cenv) . 
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•  %  error,  code  added,  before:  every  node  contradictory! 

do_te3t_env_3ub9umed ([ 1 - 

I  ^ 

do_te3t_env_3Ub3umed( (H IT) ,N,Cenv) 

environment (H,Na,A33, No, Contr) ,  ( (Contr  —  [], 

env_3ub3umed(H,Cenv)  %  H  3ubsuned  by  Cenv  (H>»Cenv) 

) 

-> 

(retract (environment (N, Na, A93, No, Contr) ) , 
aaaertz, (environment  (H, Na,  Ass, No, Cenv) ) , 
remove_env_f.rom_label3  (H,_) , 
do_te3t_env_sub3umed (T, N, Cenv) 

) 

((Contr  “■  t) 

-> 

do_te3t_env_subsumed (T, N, Cenv) 

(retract (environment (H, Na, Ass, No, Contr) ) , 
asserts (environment (H, Na, Ass, No, Cenv) ) , 
do_test_env_3ub3umed (T,  N,  Cenv) 
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